Planning for Modern Authentication – Part 1: User Authentication

PowerON 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.

Written by

Leo D'arcy

Leo D'arcy

Senior Consultant

04 Nov 2019

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 1st 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. 

Synchronized 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 2 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.  

Keep Up To Date - Join the Mailing List

The team are here to help

If there are any questions and want to learn more about PowerON’s services or Solutions, please get in touch and a member of the team will be in touch shortly. 

  • PowerON, Stanley Harrison House, York, YO23 1DE
  • 0800 3029280
  • info@poweronplatforms.com

Contact PowerON

Leave a Reply