Choosing the Right IAM Solution

Identity and Access Management (IAM) is one of the critical components of any commercial software. As the name suggests, IAM solutions cover the identity of the users, their roles, privileges, authentication, and authorization. Long story short, IAM is based on proven industry-standard protocols and is the backbone of software security.

Because access management is a complex topic, the engineering teams usually start with a simplistic local authentication model. In such a case, the application itself manages users — and their passwords — and serves a login screen to the user whenever he/she needs to authenticate. This is an easy solution that, unfortunately, reaches its limits once the software matures, and the users expect integration with various single-sign-on providers, self-service registration, password reset, and integrations with other products. Moreover, security engineers on the customer’s side require adherence to certain policies — usage of multi-factor authentication, password complexity, and reset policies. The complexity of the once simple local IAM increases exponentially, and it makes little sense to try to implement all these features yourself using only basic libraries. As the IAM landscape is vast, the protocols are complex, and it is really easy to code something just imprecise enough to open doors for the attacker.

A better option is to choose a trusted IAM component and replace the existing local authentication logic. And it pays off to perform the switch proactively since the authorization feature requests tend to result in completely custom data-centric approaches that are hard to fit into any standard model (regardless of how flexible this model claims to be).

IAM Features

Multitenancy Support

Depending on the nature of your product, you may have a need for explicit support for multitenancy. This is generally done using realms. Where a realm is an isolated set of users, roles, permissions, SSO configuration, and other IAM objects — and can be seen as a logical instance of IAM. Vendors without multitenancy support often suggest using user groups instead — this is, however, a suboptimal solution because the individual tenants need to have their own policies in place (password rotations, password complexity, account lockout…), custom identity brokering settings and bespoke user roles.

Another suggestion is to use an instance of IAM per tenant. This is viable from the IAM perspective since realms are logical instances; here, we use physical separation instead. The biggest downside is the operations of the fleet of servers; for example, if you have 50 tenants and you want to have highly available deployment, you’ll end up with at least 100 instances — for elementary redundancy. Unless all your tenants are really large organizations, the utilization of the servers will be negligible. What will not be negligible is the utilization of your ops team.

So, if your product is multitenant in nature, be sure to look for a solution that fully supports it.

Supported SSO Protocols

OpenID Connect (OIDC, which is built on top of OAuth 2) and SAML 2 are the two most widely used SSO protocols. The IAM solution should support both the receiving side, in case your customers have some preference, and also the internal side towards your applications. While I would recommend using OIDC for all modern usages, especially if you are able to make the choice, it may happen that you’d like to include some 3rd party product in your suite that happens to only have support for SAML 2.

Authentication

Unless you plan to rely solely on a customer’s IdP for authentication, you will need to pick an IAM tool that has a mature set of authentication features. This includes a login screen, you may want to white label it, and there should be a separate per tenant/realm as every customer may have different means of authentication — such as different remote IdPs. The screen should have protection against brute-force attacks, such as lockout.

To protect information stored by our systems, or privileged accounts, it is likely that you’ll encounter requests to support multi-factor authentication (MFA). MFA may be based on the possession of a device or preconfigured authenticator application that provides one-time passwords (TOTP, HOTP). Alternatively, the code may be distributed using some additional channel (push notification, SMS, email…). Some clients may ask for other types of a second factor — such as biometrics or keycards. If you have any of these needs, ensure that the IAM vendor either supports it directly or there is a possibility to build a trust chain between an external authentication provider and the IAM.

When it comes to the actual process of authentication, the IAM may either authenticate the users locally — compare username and a hash of password against its database — use identity brokering or external user storage (user federation).

Identity Brokering

Identity brokering is the capability of the IAM server to act as a middleman between your protected products and the remote Identity Provider (IdP). The remote IdP may either be a social login (login via GitHub, Facebook, Twitter, or Google…) or a provider offered by your customer. Authentication is delegated to the third party with identity brokering, so the user never inputs his credentials to your IAM but always to the trusted provider on the customer’s side. This greatly improves security as the users can be instructed to input their credentials only and only to the trusted provider’s login screen. No other internal system ever prompts them for their credentials. As a result, the attacker cannot easily fake an additional login screen.

Identity brokering relies on a trust chain between the customer’s IdP and the IAM server (acting as a broker). The trust chain is preconfigured (credentials, certificates) on both sides and communication is strictly performed over a secure channel.

It is quite common to use identity brokering to split responsibilities between the product IAM and the customer’s IdP in a way that the product IAM provides authorization while the customer’s IdP handles authentication only. This split makes complete sense for both sides, as the customer’s security team can enforce all policies that are valid in their context (password rotations, usage of MFA devices, brute force login protection…), while your team may focus on the business logic specific aspects that are tied to your applications (which user is entitled to perform what action).

User Federation

Alternatively, the authoritative source of users is not inside the IAM solution itself, and it rather replicates the users from the authoritative source (LDAP, custom user management). And while the remote system may allow you to fetch users, it will often not allow you to fetch hashes of passwords. Also, the system may not support any SSO protocol. As a result, you need to ask the user for his/her credentials (IAM login screen) and relay the credentials to the remote system, which will tell you if the credentials match.

Since the remote authoritative user storage may be a completely bespoke or archaic system, this is commonplace for extensions/plugins of the IAM server. If you deal with on-premise or legacy systems, the pluggability of the IAM may be a critical feature for you. On the other hand, if you integrate mainly with modern cloud-native systems, which usually offer standard interfaces, pluggability will be significantly less important for you.

User Management

As alluded to in the previous paragraph, the IAM solutions make it possible to federate users from other systems. Many IAMs also allow the administrator to create the users locally. But regardless of the authoritative source of the users, the IAM needs to provide means to map individual users to roles or attributes that are required for authorization purposes. The external system itself (such as LDAP, the customer’s IdP) can provide only the identity of the user, possibly also an authentication mechanism, because the authorization attributes/roles are specific to the business logic of your product and must be provided within the context of the product (via the local IAM).

User Profile

IAM is also the ideal place to store user-specific configurations — such as title, name, preferred locale, and units of measure. The IAM usually provides a configurable user profile page, where the user can input his preferences, which are then passed to all protected systems, ensuring consistent user experience across multiple products.

Authorization

When it comes to authorization, it is important to distinguish between role-based access control (RBAC) and attribute-based access control (ABAC; also, policy-based access control).

Role-Based Access Control

Role-based access control is a fairly trivial affair. The administrator assigns roles to the user. The roles may be broad such as viewer, editor, or more granular permissions, such as can-edit-articles and can-publish-articles, and some systems support composite roles, so the editor role can wrap multiple smaller permissions. But anyway, once the user is authenticated, the system issues him some form of a token (in the case of OIDC, its JWT bearer token) that contains all the roles assigned to the user. The protected product can introspect the token to retrieve the roles and decide which activities the user is allowed to perform and which are forbidden.

Attribute-Based Access Control

Role-based access control is simple to implement but has one downside — it does not scale well. Consider that the user has the privilege to publish articles only in some contexts. For example: only if the article belongs to some particular section (geographical, news, weekend supplement…) and there may be dozens of sections in the news. Or, to make things more complex: the writer and editor of the article must be two different persons. The editor of the article must have certain skills in order to be able to review the given article. In role-based access control, this results in a combinatorial explosion of privileges, and the complexity does not end here: the editor of the evening issue may have permission to publish only during the day, while the editor of the morning issue only in the evening — so the permissions are in fact dynamic.

To handle this complexity, we need to have an engine that is able to evaluate these policies. This is exactly how ABAC is structured. The product that wants to protect its resources (articles, publications…) describes these resources to the IAM server using attributes. For example, this article was created by author.userId=123, language=english, section=sports. All the other objects in the IAM also have assigned attributes; for example, the userId=145 has roles=[editor, author], spokenLanguages=[english, german], sections=[sports, news]. Lastly, the administrator — or an automated process — created a policy that forces that article.author.userId != editor.userId AND editor.spokenLanguages.contains(article.language). Please note that the policy and the attributes are data of the IAM server. These are not compiled as rules to the source code of the product.

Now consider that the editor wants to publish some article. When he invokes the protected activity, the product encounters a policy enforcement point and finds out that it does not know if the user is entitled to perform the action. The product now contacts the IAM’s policy-decision-point that evaluates all associated policies and returns its ruling if the user can or cannot perform the given action.

Even though this flow is complex, it is also very flexible since it accommodates time-based decisions, automatically reacts to changes in data (the editor changes the department and now works only for news), or allows users to delegate their permissions to other users (for example: when they are out for work).

RBAC or ABAC

When deciding if your product should use RBAC or ABAC, I would argue that it’s best to start with RBAC because it is significantly easier to implement. Once your product matures, you can always switch to ABAC since it’s a more powerful concept that also contains all RBAC features. However, unless you know that your product will always have only simple authorization requirements, make sure that the IAM solution supports both.

Other Notable Features

UI and API-Centric Design

You will need to decide if your customer’s administrators will directly access the UI of the IAM tool; if this is the case, you will likely want white labeling support. Secondly, if your product is sold in multiple markets (or it is a future possibility), it is advisable to investigate localization support of the user interface. Lastly, you’ll want to take a look at the permission model of the IAM UI itself — as you’ll likely have administrators operating at multiple levels (admins of your company, privileged administrators of the customer, and possibly several other less privileged roles with the ability to change only some aspects of the IAM behavior — such as create users with some particular set of roles).

A more involved approach is to use the IAM UI only for administrators on the side of the product company and build a separate UI for the customer’s administrators. While this increases the scope of the project, the resulting UI will follow the same UX patterns as the rest of our portfolio. Also, it will be easier for you to guide your users, customer’s administrators in this case, through user provisioning and role privilege assignments, and other tasks that will be performed by the customer. This approach depends on the IAM’s APIs. You will want to ensure that the IAM was built in an API-first fashion and all actions that can be performed via UI have also their counterpart in the APIs.

Self-Managed vs. Hosted

A difficult decision to make is if you’d like to host the IAM yourself in your data center or if you prefer to use a SaaS offering. Both of these approaches have their pros and cons. With self-hosted, one has fine control over the availability of the solution; bear in mind that downtime of the IAM will likely make all your products unavailable for customers. In case you go with a SaaS offering, you need to have full trust in the provider that the SLAs are accurate — as few credits for downtime will be unlikely to recuperate your losses from downtime.

A second consideration is the already mentioned pluggability of the solution. It is more likely that a self-hosted solution will allow you to write custom implementations of certain aspects (user federation, authentication, token mapping, auditing, etc.).

Summary

In the previous paragraphs, we went through many of the most important aspects of IAM solutions. While the IAM tools are complex pieces of software, they are complex for a very good reason — security is hard, and the tools need to be flexible in order to cover the needs of different types of applications. Even though one may be tempted to short-circuit the complexity by writing his/her own implementation, I would highly advise against this idea and recommend the usage of well-tested and established IAM tools. The IAM tools that are available in the market (both OSS and commercial) are battle-proven, feature-rich, and often backed by a company with a good record of writing reliable enterprise-grade software. You may choose if you’d like to go with a completely free self-hosted solution or if you’d prefer commercial support or even a hosted SaaS solution.