Previous blogs in this series have talked about the five fundamentals of a good IAM solution (as a quick reminder they are Authentication, Authorisation, Auditing, Architecture and Automation).
The 3As of Authentication, Authorisation and Auditing are a tried and trusted approach and many of an article has been written about the functionality required (or in the case of a blog by a vendor, the functionality they provide and why it is a thousand times better than anyone else).
It is therefore slightly unusual to have architecture listed, especially as it’s not a tangible piece or pieces of functionality, it’s more of a concept.
The Fundamentals of Architecture
This article isn’t going to go into standard architecture concepts such as resilience, security, performance and maintainability. This article is going to focus more upon the Identity specific components that need to be considered to make an IAM solution meet the standard architecture concepts.
Every solution is different either because of different use cases, different technologies or just different way of doing things. It is therefore difficult to be prescriptive about an exact structure, but there are a number of considerations
- Identity Stores
- Application Integration
- Endpoint Integration
- Integration between IAM products
- Integrating non-standard products
- Zero Trust
- Shared Security Model
Identity Stores
The first word of Identity and Access Management is Identity (obviously) and that signifies the importance of storing identities. Before talking about where to store all of those identities it is worth considering where those identities come from.
The most common assumption is that they come from a single source, namely your HR tool. This though is likely to be an error of judgement and one that can limit the functionality of the IAM. The error is that often not every user will be contained in the HR system. For example, consider contractors, third party suppliers, gig workers, consumers etc. It is likely they are not in the HR system.
By not considering these non-hr users it can be an issue later when you consider authentication and access to your systems. These then become fringe users with fringe user cases and solutions can then become bodged to accommodate.
With different inputs, these users need to be stored. Often it is considered (and one often promoted by technology vendors) that all of these users are stored in a single location. That is true, but not recommended.
If you take into account security and look at what each type of user (or user persona) actually needs, then there is an argument to separate out each type of user. For example, consumers will not need the same access to resources as a permanent member of staff. Also, they are likely to be managed entirely separately and by different teams. Especially for security it is always better to limit what operations (privileges) an operator will have.
Whilst saying there should be more than one identity store, care should be taken not to have too many and you may end up duplicating users in multiple stores. Duplication should always be avoided as this makes management difficult and can end up leading to risky identity accounts such as zombie/orphan and stale accounts.
Application Integration
Integration with applications again is very fundamental (again think of the word Access in IAM). Integration with applications is generally for a number of reasons, managing users, authentication and authorisation.
Most applications will force their own store to be used, if only so they can keep track of the number of licenses being used (i.e. money you owe). That cannot be avoided, but it’s the provisioning and deprovisioning of the identities in these application stores is important. There are a few approaches here.
Firstly, is to use the SCIM (System for Cross Domain Identity Management). This standard protocol allows for easy integration.
Secondly, use an API. The APIs can be more difficult to integrate with as they are often non-standard and do require some technical knowledge to work with them.
Thirdly is group membership. Most identity stores will allow for users to be grouped together. An application can then be pointed at these groups and told to only work with these users. (This is assuming the application supports this).
This approach has its merits in that user management is handled from a central location. The argument falls down when you consider security and who is to manage and whether they are only working with the end application. If they are, then you don’t want to give them permissions to work in your main identity store.
For example, consider a VPN and Active Directory. You could configure your VPN to take users from a number of AD groups. Let’s consider the case where you have a separate network team and a team managing AD (Infrastructure or IT). Should the network team be given permission to access and manage parts of the AD infrastructure?
From a strict security and zero trust perspective the answer is no. The counter argument to this is that AD has sufficient permission controls to handle this.
When considering application integration for Authentication look for protocols such as SAML, OAuth and Fido. All of these will allow for the authentication process to be augmented. By using an Authentication or Access Management solution a consistent user experience can also be applied.
SAML and OAuth also provide additional benefits when considering authorising access to an application (assuming a user has been provisioned and granted access in that respect). The dynamic and conditional policies can further enhance the security of an application.
Endpoint Integration
Endpoints has many meanings and interpretations, but for the sake of this article it refers to computers (whether end users or servers), mobile devices and network nodes such as vpns and firewalls.
The consideration for these is that at some point a user will have to authenticate and have access authorised. Many devices such as computers and mobile devices have their own built in authentication. The authentication method tends to be username and password (or pin number). This can be improved with biometrics and if supported FIDO for using different factors of authentication (such as biometrics, smart cards etc).
In some cases to support this additional factors integration with other infrastructure is required (consider PKI for smart cards). All of these do require one thing, an identity.
Much like applications thought has to be given to how to integrate with the identity store. Thank fully common products like Active Directory easily provide that. Question is whether the endpoint needs to be domain joined. However, with modern cloud based connectivity they are not and then authentication is generally local. In this case authentication to internal resources is delayed and repeated when required.
In such cases the end point will need to be integrated with an authentication solution.
For network nodes, these are managed slightly more easily as they tend to be a part of the internal infrastructure with access to internal resources. In such cases the same architecture as described for applications works here.
There has been a marketing buzz term for quite a few years about “Identity is the new perimeter”. Unusually for vendors this shouldn’t be considered marketing BS. It is actually a good concept. The importance is not so much the physical endpoint, but it is where the identity is to be used. The identity in this case is the one that is used to access an organisation’s resources. It is acceptable to have a different identity to log in to a machine but to access the resources a corporate specified one should be used.
Integration between IAM products
Consolidation in the IAM market place has meant that the number of products required for an IAM solution has reduced over the years. Despite what some vendors may claim, the minimum is likely to be three (IGA, Access Management and PAM). However, some of the more established vendors can have 20+ products or packages to support all the functionality.
Irrespective of the number of products chosen it is recommended to treat each product as an application. Therefore, consider using standard protocols or APIs for integration.
Extra consideration should be given to security around the products. Ensure administrators of each product are protected with MFA. Misuse of the IAM products whether accidental or malicious can cause significant impact in connected systems.
Integrating non-standard products
This is always tricky, especially with legacy on-premises solutions. Often not much can be done if they do not provide integration with LDAP (Identity Store) or provide an API.
There are some options though but do involve additional products. Some full Access Management systems do provide a wrapper around these systems and can enforce authentication and provide authorisation capabilities.
Alternatively, virtualisation technology such as citrix, vmware etc can allow for an application to be installed within their systems and again provide additional authentication and authorisation. These virtualisation technologies also fall under the category of managing applications.
Zero Trust
Zero Trust is a concept many a vendor will talk about regardless of the technology they provide. The concept of Zero Trust is important when designing an architecture.
The premise is that users and administrators only have access to what they need to have. This is often implemented using configuration to segment and silo operations. It is worth considering that this can be achieved through separate installations rather than one.
The downside to this is that there a greater management overheads and potentially greater costs in infrastructure to support multiple installations.
A decision has to be made as to how important a full Zero Trust architecture is to have.
Shared Security Model
This is often an unknown concept to be considered, but it is a relative new consideration for architecture.
Many new platforms do provide an extensive range of security. The issue is that the security is for their infrastructure and not necessarily the infrastructure you are placing in the platform. Many organisations consider the provided security is enough for their infrastructure.
The advice here is not to assume that and adopt what is called a Shared Security Model. That is use the provided platform security but also provide additional security using conventional products such as MFA and Access Management.
Summary
Architecture may not be considered a fundamental part of an IAM solution. Functionally wise that may be true, however a good architecture will ensure an effective solution.
Over and above the typical architecture considerations of resilience, security, performance, and maintainability additional thoughts have to be made for IAM specific functionality.
Use of standard protocols such as SCIM, SAML, OAuth and Fido can help provide out-of-the box compatibility. Additional integrations can be provided through use of APIs but this often needs some technical skills. An easier approach, assuming it’s provided by an application or endpoint, is to use groups in the Identity store to control access. This does mean that management is outside of the target system.
Zero Trust should be considered as part of an architecture design, but it can lead to multiple and separate installations which can increase management and infrastructure overheads.
Modern cloud platforms provide extensive security but often only for their systems. Any infrastructure installed upon the platform may not be covered. Therefore a Shared Security Model should be adopted in which additional security is used to augment the security of the platform.