The need to securely authenticate and authorize users and services is not restricted to the traditional IT infrastructure. In the cloud, where it takes just a few clicks to sign up to a new service and roll it out for the whole company, staying in control of your own identities is of particular importance. Only centralized user accounts allow you to keep control of all passwords and policies and keep you solely responsible for preventing leaks of authentication data. Luckily, centrally managed accounts are one of the things users like as well. It gives them the option to log in to many cloud services with one single identity that they use for their workstations anyway.

Therefore, let us first explore the benefits of running your IdM before stepping into the technologies used to connect some of the favorite cloud services.

Why Stay in Control of Your Identities

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 any more 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 genuinely 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.

Firstly, 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 your identities or to accept the management overhead of having two separate systems.

Secondly, 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 others, 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 as well. 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 utilize the combination of LDAP and Kerberos is that an LDAP connection is established only between the authentication source and the service. The user enters his credentials thus with the service, and the service is then using the LDAP connection to authenticate the user. This process allows any service to phish the credentials of your users.

Kerberos, while offering a secure and trusted way to verify the password, has the disadvantage that the user needs to be able to reach the KDC on a protocol and ports that public networks most often block.

Thus, both protocols are more commonly used 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 the user, the authentication source, and the 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 as 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.

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 little standardization between these APIs, thus the need for many different connectors.

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.

Conclusion

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, adding to the convenience of managing your user base in a cloud-centric world.

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, which encompasses your cloud services, should be a fundamental part of any IT department.