We have worked with a number of customers to enhance their modern authentication strategy. This is often done to increase supplier flexibility as well as start to remove dependencies on existing VPN and Active Directory dependencies. It can also improve the end user experience by minimising the number of accounts and passwords needed and can allow greater delegation of control to solution administrators.
Read part one – Planning for Modern Authentication: User Authentication
Introduction
One of the major trade offs between solutions and the setup time and complexity is the ability to synchronise account permissions and identities between the originating Azure AD tenant and the solution identity. Each solution will handle this differently depending on the identity option selected in part one of the series.
Native Azure AD Integration
Due to the fact that Azure AD is the originating database and the authenticating database there is no need to synchronise accounts. All Azure AD users and groups can be used within the application and will always be up to date.
Application Hosted Synchronisation
Certain applications provide their own hooks into identity providers to collect the required information such as usernames and group details. This is often simpler than setting up custom configuration and because it is managed through the application itself is unlikely to need significant additional infrastructure or configuration.
It is worth noting that since each solution will develop their own integration there can be a significant variance in concepts and functionality. It is recommended that these systems are trailed prior to committing to full rollout.
SCIM
SAML 2.0 is purely an authentication mechanism which means that there must be a user object already in the solution’s database to map the authentication request to the required permissions. To automate the provisioning of this there is a separate technology named System for Cross-domain Identity Management (SCIM). This provides an event driven model for solutions to receive user and group updates directly from an appropriate identity provider (of which Azure AD is). This allows compatible solutions to automatically generate the users and groups based on Azure AD groups and allow authentication via SAML.
It is worth noting that since each solution will develop their own integration with SCIM there can be a significant variance in concepts and functionality. It is recommended that these systems are trailed prior to committing to full rollout.
Custom Synchronisation Script
Where solutions don’t specifically support SCIM they may support a custom API. This allows the development of custom scripts which can read the current memberships from Azure AD and create the required accounts and groups in the solution.
Due to the complex nature of identity logic it is likely that this will only provide limited synchronisation and is likely to lag behind actual group membership. It also relies on the APIs continuing to be available with any changes potentially breaking the script and requiring further development work.
Windows AD
Some on-premises solutions can talk directly to Windows AD for user management which removes the requirement to synchronise accounts or the synchronisation takes place as part of the configuration.
While this works it locks the solution into having direct, private network access, to corporate systems as LDAP is an inherently private protocol with no real way to connect over an untrusted network. This also requires administration to take place via Windows AD. This is not easily delegated to solution owners and doesn’t natively support additional security features such as 2 factor authentication and access reviews.
Manual Setup
Where a solution doesn’t support any of the above setups it is possible to still use Single Sign On but have the accounts manually created. For small numbers of users (< 10) this may even be desired due to the cost or complexity with setting up an automated provisioning process.
For a medium number of users (< 75 with a low churn rate) a manual setup may be acceptable depending on the solution however the cost in time and ongoing maintenance for a central IT team should be considered in any renewal or purchasing decision.
For larger user bases or ones that have a significant churn in their user or access control requirements, applications should be migrated to using one of the above account automation technologies or a replacement be thoroughly considered.
So there you have it, a number of ways of implementing account synchronization to enhance Single Sign On (SSO) and minimising administrative workloads!
