When administrators think about user management (IdM), they often only keep an eye on traditional IT systems. But even in the cloud, where you can buy new services with just a few clicks, it’s extremely important for companies to keep control over their users if they do not want to lose control over who has rights and access in the organization. Otherwise, a dissatisfied or dismissed employee can quickly become a real threat to the entire corporate IT. Or the failure of subsystems can mean that the entire IT can no longer be accessed and all processes in the company are stopped.
With a centralized user management it is possible to effectively enforce password policies and prevent a single external service from simultaneously compromising a large number of passwords without allowing the administrator to take remedial action. But also for the users a central user management offers a noticeable advantage, because single sign-on allows them to securely log on to different services with a central password.
Therefore, let us first explore the benefits of running your own central user management before stepping into the technologies used to connect some of the favorite cloud services.
Why an Open IdM is Better for Your Cloud Services
Today many identity management systems are offered to big and small companies. Some are based on open source software while others are based on proprietary software. However, many of them have in common that you cannot easily migrate your identities to a different service, for example, if you are not anymore happy with it.
Only if you have access to the backend, as you have with UCS or other Open Source Solutions, in addition to the shiny interface, can you truly choose where you want to store your identities. Having access to the backend and platform and being able to determine where your IdM runs, gives you distinct advantages over a closed management system that only provides you with a frontend and some connectors.
These advantages are:
- An open platform and a directory allow you to connect your identities to the services of your choice instead of connecting them to the services approved by your IdM vendor. While in many cases all will use the same underlying open protocols to facilitate the connection, it is all too easy for a provider to block connections if a competing offer gives a considerable incentive to do it. Just imagine, you successfully migrated all your emails to a new email provider and suddenly your IdM provider decides not to support this provider anymore. You then have to choose whether to migrate your emails and identities or to accept and deal with the management overhead of having two separate systems.
- If you are in control of the backend, it becomes possible to support further protocols by combining different open source projects. As an example, UCS currently offers, among other things, connectors to quickly provision and manage identities used within Office 365 and G-Suite. As the backend is well documented and accessible to anyone running a UCS instance, it only will take a few lines of Python code to provision Dropbox with the same information already in use. Without access to the backend, it becomes impossible to do these changes.
Technologies for a Connected Cloud
After looking at the reasons why you would like an open Linux-based identity management system, let us focus on the technology used to create a central user identity management system.
Traditional Authentication and Authorization Stack
Traditional authentication and authorization protocols, such as LDAP and Kerberos, have been designed to work over both unreliable and untrusted connections. Thus, they can be used for authentication in the cloud, too. And often you find them when connecting your services, sometimes under the name AD services. LDAP connections can offer both authentication and authorization protocols. Or it can only provide the authorization and user management part, leaving the user authentication to Kerberos.
The reason to use the combination of LDAP and Kerberos is the following:
An LDAP connection, on the one hand, is established only between the authentication source and the service. The user enters his credentials with the service and the service is then using the LDAP connection to authenticate the user. This process thus allows any service to phish the credentials of your users.
Using Kerberos, on the other hand, offers you the possibility that passwords never leave the own terminal, i.e. they are neither sent over the network to the service nor to the user management system. Kerberos thus offers a secure and trusted way to verify the password. It has, however, the disadvantage that the user needs to be able to reach the KDC on a protocol and ports that public networks most often block.
This is why both protocols are more commonly used together in on-premises scenarios where the IT department is in control of both the systems and the network. Of course, both offer an excellent choice as a backend for the more purpose-built protocols, a scenario which can also be found in UCS.
Purpose-Built Authentication Protocols
Alternatives to the traditional protocols are purpose-built languages that utilize many of the design ideas behind Kerberos but are working with HTTP connections and cookies for the communication between user, authentication source, and service. The three most popular ones are the Security Assertion Markup Language, commonly known as SAML, the Central Authentication Service, in short CAS, and OpenID.
OpenID has its origin in a more web-like approach. Many independent notes trust each other to authenticate their users and provide parts of their user identities without releasing their passwords. What differentiates OpenID from the other two protocols is that there is no needed trust between the identity provider and the service provider. The basic idea was that you provide a unique URL from your identity provider to authenticate yourself and any service provider will accept your identity.
SAML and CAS, in contrast, rely on a controlled federation of service providers and identity sources. Usually, the administrator of the identity provider has to establish a trust relationship to a particular service before the user can authenticate with his account at that specific service.
The authentication itself is similar in most cases. The user goes to the website of the service and enters his ID, in most cases an email address. Afterwards, the service redirects the user to the particular identity provider that was identified to belong to the address or domain. The user enters his credentials at the identity provider website and gets a token that authenticates him at the services. This description is only a general overview. There are numerous minor differences and possible enhancements that set the different languages apart from each other, but all identify the user and authorize him to use a particular service, often by using only one password per single sign-on.
User Defining Attributes
Identifying users is an essential but only small part of managing your users. However, it is the better defined and standardized part. The more significant challenge often is to provision the users in a particular service and to provide well-known attributes associated with an account such as the name of the user or his email address.
Just think about the following scenario:
The company uses the first letter of your first name, the first letter of your last name and a random identifier, e.g., KK987654@idp.univention.com as the identifier for authenticating the users. G-Suite will at least need your email and name to create a professionally looking sender in every email. Dropbox, on the other hand, might need your group memberships to add you to a specified folder but might also want your email to be able to notify you when one of your folders changes.
Unfortunately, most services provide their custom API, making connectors, such as our G-Suite connector, necessary for provisioning users within the respective applications. Of course, most services offer their toolkits for the integration. However, there is still little standardization between these APIs, thus the need to use many different connectors remains.
For some time it seemed that OAuth appeared to gain traction in overcoming this particular issue. OAuth thereby represents a standardized set of APIs that allow a user to share its identity and attributes without sharing the actual login. It is still common today, whenever you hit a button “Log in to Google” or “Log in to LinkedIn”, there is an OAuth data transfer happening in the background. However, this convenience does not extend beyond the handful of providers in the customer space.
Providing centralized identities in the cloud to your users, enables you to manage your users in one convenient location and provision them to different cloud services. The same applies for changing or deleting a user. This not only saves you a great deal of time, but prevent you from gradually losing control of the users in your IT environment, thus opening dangerous gates for conscious or unconscious damage to the system itself, the processes and data.
Most importantly, however, it increases the comfort of your users who only need a single username and password without needing to worry that one hacked service would compromise all other logins.
Accordingly, a central identity management system, such as UCS on Amazon, which encompasses your cloud services, should be a fundamental part of any IT department.