We’ve 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.
Introduction
It should be noted that Authentication and Account Synchronisation can be separate however are extremely complimentary. Authentication is the process of a user being verified against a list of known attributes (such as a password) while Account synchronisation is the process by which the solution knows about the user and what roles and rights, they have within it. In this part we will be discussing Authentication, part 2 discusses the options around account synchronisation.
Authentication
Native Azure AD Integration
Azure AD is a fully OAuth 2.0 and OpenID Connect compliant solution. This means that it is possible for application suppliers to write their application in such a way that it natively uses Azure AD for user and group management without any additional configuration or setup. This has the advantage of often having good first party documentation and doesn’t require any synchronisation of users or groups from Azure AD for Role Based Access Control. This solution is the most desired as it often requires the least effort while providing a consistent approach to user management.
SAML 2.0
SAML (Security Assertion Markup Language) 2.0 is a standard for sharing token based authentication between applications. This allows a user to be authenticated by Azure AD and then pass that token silently to the application which can read it to link the sign in information with an account in its database. As this matching logic is completed on a per solution basis it is up to the application to expose these concepts within its application.
As such there can be a great deal of variance between applications as to how SAML accounts work. Some treat native and SAML accounts differently, others map the user based on the username and as such don’t distinguish between native and SAML logins. This solution is preferred over others due to the fact that authentication is still taking place within Azure AD which provides the benefits of centralised control and conditional access.
SSO via Windows AD
Some On-premises applications allow authentication and access control via Windows Active Directory (AD). This has many of the benefits of Native Azure AD integration but had the major drawback of being tied to an on-premises domain. This limits security as Windows AD was not designed for internet accessible access so lacks a number of security features built into Azure AD. This often limits access to only users with access to a VPN.
Access control can also only be done by Windows AD groups which is often done via a central IT team. This reduces the ability for business departments to self-regulate access and often slows down new user onboarding.
Synchronised Accounts
Some applications will take a copy of a user so that they can authenticate to the application without the user understanding that they are authenticating to a completely different system. This is relatively uncommon as to enable identical password use, the application effectively has to break the encryption on the originating password or follow the same hashing processes as the original password. As such it is not recommended from anyone other than a highly trusted source.
Native Accounts
Native accounts are separate user accounts stored in the solutions own database. This is the simplest setup as it is often the default however comes with a number of limitations. The main one being that users have to manage and remember separate usernames and/or passwords. This can increase administration overhead where users forget them.
There are also significant security implications to this including the decentralisation of control, lack of standardised security practices such as enforcing two-factor authentication, variable encryption and storage techniques and most importantly when a user leaves a high probability that the user will continue to have access for a time after they have officially left the business.
Active Directory Federation Services
Active Directory Federation Services (ADFS) allows two systems which don’t share any infrastructure to trust the identities of each other. While this works great from a user perspective it requires a significant on-premises setup to ensure that it is highly available. It also suffers from a complicated claims query language which can be hard to modify without impacting users. A significant number of organisations are in the process of removing ADFS from their environments and as such don’t wish to extend their usage of the technology any further.
Conclusion
In this post we’ve discussed a number of ways of implementing Single Sign On (SSO) and the preferences we have for modern authentication. If you would like any further help with your own journey towards the cloud please feel free to get in contact here.
Stay tuned for the next part which discusses account synchronisation in more detail.
