Authentication is an interesting topic. In this blog post we’ll explain why, explore some of the challenges and offer a solution that elegantly addresses those challenges in Xribe.
Identity is crucial
Identity – who you are and what groups you belong to – is a cornerstone of any security program. User management, onboarding and offboarding procedures, password policies, access policies, all of this is centered around identity. Your identity is the information upon which is decided what you’re allowed to see and do in a system. To establish your identity, you need to be authenticated; you need to prove who you are. Often this is done by providing a password. For more modern, or more security-sensitive systems a second factor like the output from a one-time password device has become common as well. After you’re authenticated and your identity has been established, the application can authorise you to access certain things or to execute certain operations based on it. People that are members of the group of administrators for example, will probably have access to more functionality and be allowed to do more things than regular users.
Authentication is not easy
The way users prove their identity is constantly evolving. Passwords were commonplace, but 2-factor authentication is becoming more and more common, especially for security-sensitive applications. Cryptographic devices as promoted by the FIDO Alliance will probably become more and more common in the years to come. Other counter-measures are becoming more and more the norm as well. A good authentication system will recognise and remember the devices and locations you normally sign in from for example. If it detects something out of the ordinary, it will double-check whether this is a valid attempt.
Proving who you are is typically not something users enjoy doing. Entering passwords and copying numbers from tokens are barriers standing between a user and the things he or she wants or needs to do. Consequently, a lot of effort has been invested in solutions that allow a user to log on once and then have the proof of his identity be communicated to other applications and systems automatically. This is called Single Sign-On and the goal is simple: have a user sign in on their laptop once, and then make it so that they never have to type a password or enter a code again. Unfortunately, many different solutions exist (Kerberos, SPNEGO, SAML) providing parts of the global solution and none of them are trivial to implement or integrate with.
Because authentication is a cornerstone for security, it is a focal point for people attacking your system. Brute-forcing passwords, listening to network traffic, abusing password reset functionality, fake login screens, intercepting sms communications; there are a lot of attacks possible and the smallest slip-up has grave consequences for the security of the entire system.
Changing requirements and complicated protocols that are actively targeted by attackers, authentication certainly is no walk in the park.
Provisioning is cumbersome
Managing a list of users is an important albeit somewhat tedious job. Procedures need to be in place to make sure new hires are enrolled, position changes are processed and people leaving the company are removed. This is relatively easy if there is only a single application that needs to be updated. If however, Marc from marketing has access to many different systems and online applications, all with their own set of users, a change in the responsibilities of Marc might require a lot of updating and a single forgotten application can lead to security issues or frustration.
Centralise
The natural way to make all of this more manageable is to centralise authentication and user provisioning. Applications and systems should delegate the authentication process to a separate system specialising in authentication.
With the growth of cloud services, the need for cloud-based identity providers grew as well. We see several popular cloud applications like Google and Facebook providing delegation functionality. More business-oriented providers like Okta, OneLogin or Ping Identity sprung up as well. Finally, Microsoft started offering a cloud-based version of their Active directory solution with good integration with the on-premise Active Directories. As a cloud service you can now offer users to delegate the authentication to one or more of these providers. “Log in with Google”, “Log in with Facebook” or “Log in with Microsoft” are options I’m sure you’ve encountered by now somewhere.
Cloud services that delegate authentication get statements they can trust about the users that sign on to the platform. But what do you do when a new user you never saw before signs on? Sometimes you can give the user default rights, but this is not always possible or correct. Removing users is also a problem as the service only sees users when they log on. If they are removed, the cloud service doesn’t know whether the user is removed and its data should be deleted, or if he’s simply inactive. What is needed is identity providers keeping the cloud services informed about the users it manages. This is the reason behind the SCIM system. Using SCIM, identity providers inform cloud services about new, changed and removed users, allowing administrators to proactively assign permissions based on group memberships and to make sure that when users are removed from the central identity provider, that they are also removed from the linked cloud service(s).
Integrate
Delegating to an identity provider might offload the complexity of authentication to someone else, but you still need to implement this delegation. Luckily, modern standards have matured that make this possible. For the authentication, OpenID is a popular choice implemented by most identity providers. Provisioning users is a bit newer, but SCIM appears to be the frontrunner there.
Azure AD with OpenID, SCIM
We’re happy to announce that we implemented OpenID and SCIM support and that it is now possible to log in using Microsoft’s Azure Active Directory instead of a username and password.
Why Azure Active Directory? Because we noticed that a lot of companies already use Azure Active Directory, often without even realising it. If you’re an Office 365 customer, you already have an Azure Active Directory account. Besides that, Azure Active Directory inter-operates very well with on-premise Active Directory setups, which still are a very popular choice for user management. This identity provider also checks all of the modern authentication boxes like 2-factor authentication, Single Sign-On and monitoring of login attempts. After linking your Xribe account to your Azure AD organisation and assuming you configured your browser to use Integrated Windows Authentication, logging in without entering a password is entirely possible today.
Authorization in Scriptura based on groups
If you want to try this for yourself, follow the steps in the documentation, wait a minute for the users and groups to be synced, assign the necessary roles and permissions to the groups and from then on you can authenticate yourself by pressing the “Log in with Microsoft” button on the login page.
Conclusion
By adding support for Azure Active Directory integration we now offer the possibility to centralise user management, enable 2-Factor Authentication and facilitate Single Sign-on.
Authentication is an interesting topic. In this blog post we’ll explain why, explore some of the challenges and offer a solution that elegantly addresses those challenges in Xribe.
Identity is crucial
Identity – who you are and what groups you belong to – is a cornerstone of any security program. User management, onboarding and offboarding procedures, password policies, access policies, all of this is centered around identity. Your identity is the information upon which is decided what you’re allowed to see and do in a system. To establish your identity, you need to be authenticated; you need to prove who you are. Often this is done by providing a password. For more modern, or more security-sensitive systems a second factor like the output from a one-time password device has become common as well. After you’re authenticated and your identity has been established, the application can authorise you to access certain things or to execute certain operations based on it. People that are members of the group of administrators for example, will probably have access to more functionality and be allowed to do more things than regular users.
Authentication is not easy
The way users prove their identity is constantly evolving. Passwords were commonplace, but 2-factor authentication is becoming more and more common, especially for security-sensitive applications. Cryptographic devices as promoted by the FIDO Alliance will probably become more and more common in the years to come. Other counter-measures are becoming more and more the norm as well. A good authentication system will recognise and remember the devices and locations you normally sign in from for example. If it detects something out of the ordinary, it will double-check whether this is a valid attempt.
Proving who you are is typically not something users enjoy doing. Entering passwords and copying numbers from tokens are barriers standing between a user and the things he or she wants or needs to do. Consequently, a lot of effort has been invested in solutions that allow a user to log on once and then have the proof of his identity be communicated to other applications and systems automatically. This is called Single Sign-On and the goal is simple: have a user sign in on their laptop once, and then make it so that they never have to type a password or enter a code again. Unfortunately, many different solutions exist (Kerberos, SPNEGO, SAML) providing parts of the global solution and none of them are trivial to implement or integrate with.
Because authentication is a cornerstone for security, it is a focal point for people attacking your system. Brute-forcing passwords, listening to network traffic, abusing password reset functionality, fake login screens, intercepting sms communications; there are a lot of attacks possible and the smallest slip-up has grave consequences for the security of the entire system.
Changing requirements and complicated protocols that are actively targeted by attackers, authentication certainly is no walk in the park.
Provisioning is cumbersome
Managing a list of users is an important albeit somewhat tedious job. Procedures need to be in place to make sure new hires are enrolled, position changes are processed and people leaving the company are removed. This is relatively easy if there is only a single application that needs to be updated. If however, Marc from marketing has access to many different systems and online applications, all with their own set of users, a change in the responsibilities of Marc might require a lot of updating and a single forgotten application can lead to security issues or frustration.
Centralise
The natural way to make all of this more manageable is to centralise authentication and user provisioning. Applications and systems should delegate the authentication process to a separate system specialising in authentication.
With the growth of cloud services, the need for cloud-based identity providers grew as well. We see several popular cloud applications like Google and Facebook providing delegation functionality. More business-oriented providers like Okta, OneLogin or Ping Identity sprung up as well. Finally, Microsoft started offering a cloud-based version of their Active directory solution with good integration with the on-premise Active Directories. As a cloud service you can now offer users to delegate the authentication to one or more of these providers. “Log in with Google”, “Log in with Facebook” or “Log in with Microsoft” are options I’m sure you’ve encountered by now somewhere.
Cloud services that delegate authentication get statements they can trust about the users that sign on to the platform. But what do you do when a new user you never saw before signs on? Sometimes you can give the user default rights, but this is not always possible or correct. Removing users is also a problem as the service only sees users when they log on. If they are removed, the cloud service doesn’t know whether the user is removed and its data should be deleted, or if he’s simply inactive. What is needed is identity providers keeping the cloud services informed about the users it manages. This is the reason behind the SCIM system. Using SCIM, identity providers inform cloud services about new, changed and removed users, allowing administrators to proactively assign permissions based on group memberships and to make sure that when users are removed from the central identity provider, that they are also removed from the linked cloud service(s).
Integrate
Delegating to an identity provider might offload the complexity of authentication to someone else, but you still need to implement this delegation. Luckily, modern standards have matured that make this possible. For the authentication, OpenID is a popular choice implemented by most identity providers. Provisioning users is a bit newer, but SCIM appears to be the frontrunner there.
Azure AD with OpenID, SCIM
We’re happy to announce that we implemented OpenID and SCIM support and that it is now possible to log in using Microsoft’s Azure Active Directory instead of a username and password.
Why Azure Active Directory? Because we noticed that a lot of companies already use Azure Active Directory, often without even realising it. If you’re an Office 365 customer, you already have an Azure Active Directory account. Besides that, Azure Active Directory inter-operates very well with on-premise Active Directory setups, which still are a very popular choice for user management. This identity provider also checks all of the modern authentication boxes like 2-factor authentication, Single Sign-On and monitoring of login attempts. After linking your Xribe account to your Azure AD organisation and assuming you configured your browser to use Integrated Windows Authentication, logging in without entering a password is entirely possible today.
Authorization in Scriptura based on groups
If you want to try this for yourself, follow the steps in the documentation, wait a minute for the users and groups to be synced, assign the necessary roles and permissions to the groups and from then on you can authenticate yourself by pressing the “Log in with Microsoft” button on the login page.
Conclusion
By adding support for Azure Active Directory integration we now offer the possibility to centralise user management, enable 2-Factor Authentication and facilitate Single Sign-on.