Protocol
OIDC for new apps, SAML where the vendor needs it.
Why. OIDC is simpler for modern apps and APIs.
Trade-off. Some CRM tools only support SAML for SSO.
CRM and business systems · Entra ID and Okta
Identity and single sign-on across CRM and business apps
One identity provider for staff, partners and customers: SAML and OIDC federation, SCIM provisioning, Conditional Access, role mapping and a leaver process that really removes access.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- ACSC Essential Eight
- SA ISMF access control expectations
- Australian Privacy Principles
Architecture
- SaaS and business systems
- People and clients
- Security and identity
- Compute and containers
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
The HR system is the source of truth. Joiners create identities, movers change groups and leavers disable the account and trigger revocation.
A user signs in once at the identity provider, with a phishing-resistant factor such as a passkey or FIDO2 key where possible. Conditional Access evaluates user, device, location and sign-in risk.
Apps trust the IdP through SAML or OpenID Connect. SCIM provisions users and roles, so accounts appear and disappear automatically.
Privileged roles are not permanent. Admins elevate just in time with approval, and access is reviewed on a schedule.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Microsoft Entra ID or Okta | Central identity, SSO, MFA and groups. | Entra suits Microsoft 365 organisations. Okta suits a neutral multi-cloud stance. |
| SCIM provisioning | Automatic create, update and disable in SaaS apps. | Without it, leavers keep access in forgotten apps. |
| Conditional Access | Adaptive policy. | Moves from static trust to risk-based access. |
| MFA and passkeys | Strong authentication. | Phishing-resistant methods defeat the most common attacks. |
| Privileged Identity Management | Time-limited admin roles with approval. | Removes standing admin rights. |
| App roles and groups | Map IdP groups to CRM profiles and permission sets. | Role changes are controlled in one place. |
| Customer identity (Entra External ID, Cognito or Auth0) | A separate store for customers and partners. | Staff and customers carry different risks. |
| Break-glass accounts | Emergency access outside Conditional Access. | An IdP outage must not lock out the admins. |
Design decisions and trade-offs
Authorisation
Coarse role from IdP groups, fine-grained permissions inside each app.
Why. Central joiner-mover-leaver, local least privilege.
Trade-off. Mapping tables to maintain.
Staff versus customers
Separate directories.
Why. Different threat models and policies.
Trade-off. Two identity systems.
Admins
Separate admin accounts with PIM.
Why. Limits the blast radius of a phished daily account.
Trade-off. A little friction for admins.
Well-architected pillars
Security
MFA everywhere, Conditional Access, short sessions, PIM and no shared accounts.
Reliability
Cloud IdP SLAs, break-glass accounts and a documented outage procedure.
Performance
Token lifetimes balanced for user experience and risk.
Cost optimisation
Per-user licences. Higher tiers add Conditional Access, PIM and governance.
Operational excellence
Quarterly access reviews and automated leaver tests.
Sustainability
Fewer duplicate accounts and unused licences.
Network, identity and data
Networking
Named locations and compliant-device requirements. Legacy protocols such as basic authentication are blocked. On-premises apps are published through an application proxy rather than inbound ports.
Identity and least privilege
Everything above. Privilege is time-bound. Service accounts become workload or managed identities. Guest accounts have expiry and sponsors.
Data and encryption
Identity data is personal information. Share only the attributes each app needs (APP 3 and 6) and keep audit logs for investigation for the policy period.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Multi-factor authentication | Essential Eight multi-factor authentication, preferably phishing-resistant. |
| Restrict administrative privileges | PIM, separate admin accounts and reviews. Essential Eight. |
| Access management | Joiner, mover and leaver automation supports ISMF access control expectations. |
| Logging | Sign-in and audit logs go to the SIEM. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOPer provider SLA. Break-glass access in minutes
- Target RPODirectory configuration held in code or exported regularly
- Scaling and limitsScales to many thousands of users. Licence tier and app provisioning limits apply.
| Failure mode | Mitigation |
|---|---|
| Leaver keeps access in a SaaS app | SCIM deprovisioning and a monthly orphan-account report. |
| IdP outage | Break-glass admin access and app-local emergency access for critical systems. |
| MFA fatigue attack | Number matching and phishing-resistant methods. |
| Over-permissioned groups | Access reviews and role design. |
Observability and runbooks
- Sign-in risk and failure dashboards.
- Alerts on break-glass use, new admin role assignments and impossible travel.
- Leaver SLA: time from HR termination to access removal.
Cost drivers and levers
Per-user licence tier and number of external identities.
- Remove unused licences.
- Choose tiers per user group.
- Consolidate apps.
Implementation and fit
Phased approach
- Inventory apps and accounts.
- Turn on MFA and baseline Conditional Access.
- Federate the top applications with SCIM.
- Introduce PIM and access reviews.
Anti-patterns to avoid
- Shared admin accounts.
- SSO without SCIM, leaving local accounts behind.
- MFA exceptions for executives.
- No break-glass.
When to use it
- Any organisation with more than a handful of SaaS apps.
- Tender responses that need access control evidence.
When not to
- Rarely applicable to avoid: this is a baseline. Scale the tier to the risk.
More in crm and business systems
Microsoft 365
Secure Microsoft 365 workplace, ready for Copilot
A Microsoft 365 tenant for councils and small organisations that is safe before AI arrives: Entra ID with Conditional Access, Intune-managed devices, Purview labels and DLP, oversharing cleaned up, and a backup copy outside the tenant.
Salesforce
Salesforce Sales and Service Cloud integrated with ERP through MuleSoft
API-led connectivity between Salesforce and a finance or ERP system: system APIs wrap the ERP, process APIs hold the business rules, Salesforce calls one stable contract, and events keep both sides in step.
Microsoft
Dynamics 365, Power Platform and Dataverse with Entra ID
A Microsoft-centric business platform: Dynamics 365 apps on Dataverse, Power Apps and Power Automate for tailored processes, governed environments and DLP, integrated with Entra ID, Microsoft 365 and Azure.
Related insights
- Zero Trust and Conditional Access for SA Government agencies and councils
- Essential Eight for SA SMEs: what buyers expect when you bid for government ICT work
- SA ISMF for ICT suppliers: what buyers expect in tenders
- Email security for SA councils and small businesses: SPF, DKIM, DMARC and stopping fake invoices
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.