Identity and Access Management (IAM/IdAM) deployment guide

Question

I'm working on a set of applications that require authentication and authorization.

Can you point me in the right direction to some architecture design for this when I want to have multiple services running and how to exactly manage service to service authentication and user to service authentication as well?

I will probably do all this through OAuth2 etc, but I'm not sure what's the proper way of deploying this.

Answer 1

Hopefully this helps.

Identity Management Systems

Identity Management System are often defined by trusted sources. These are the systems we rely on for a source of record for an individual. These are not really a single piece but a combination of systems designed to manage people.

Identity Data Trusted Source

This is data of people, typically found in your HR systems. They are wide ranging, and can be as simple as AD for a small organisation.

Authorization/Authentication Trusted Source

This is a system or systems which your organization uses for AAA. In many organizations, that is just Microsoft's Active Directory, however, there are several directory based services out there and larger organizations can have systems split into different sources.

Single Sign On

Most organizations that uses SSO within the organization likely uses some sort of Federated Identity Service which allows users to have a single ID across multiple AAA systems.

Modern Federated Services allow for both SAML and OAuth 2.0 communications. If you want to be technical, OAuth isn't targeted at Authentication, it's Authorization. It does provide a mechanism for Authentication Exchange, but that's not its intent.

SAML is on built for both, and is typical for Enterprise SSO services.

If these are custom applications, one standard I have added to my development work is JWT (JSON Web Tokens) which is not really SSO per-se, but more of a mechanism to enable SSO features in modern applications, but it can handle both Authentication and Authorization.

Common IDM systems Examples

• Oracle Identity Manager (Link)
• Sailpoint IdentityIQ Link

I work with both these systems. I have many reservations about them. Sailpoint is more modern, Oracle is, well, Oracle (Lots of ups/ LOTS of downs). I always think I could build a better one (which I might attempt for fun one day).

Do it yourself setups

Understand that IDM/IAM/IdAM (Or whatever abbr you want) are designed to provide a common set of administrative functions around people and access to resources. This includes being a central repository for identity access, role management, policy deployment, and provisioning/de-provisioning of resources. Wiki for reference.

Your actual goal sounds less like IDM and more like resource management, I.E something that is not achieved by these system specifically. A few things:

• You need to identify which systems are going to allow to authenticate and/or authorize resources.
• You should have a policy around future apps about their ability to authenticate to those systems.

I think you may want to start with Federated Services and research them. This will give you an understanding of what their purpose is. Most organizations looking at SSO at scale, are looking to Federated Services to simplify thing.

This is where the term Microsoft shop comes into play, so mentioned because all their apps are MS and can authenticate to AD. I've never been to an organization that had this but, kudos if you have that simplicity.

Answer 2

General recommendations for deployment:

1. Define secure perimeter for your solution: where is frontend, backend.
2. Use proxy or edge service (like HAProxy, Zuul, etc.) to separate frontend and public API from internal communications
3. Add Identity & Access Management as a separate service to provide central authentication and authorization
4. Protect acess to the service and secure connection to it via TLS
5. Define standards and protocols for central authentication and authorization

Usually OpenID Connect and OAuth2 are used for SSO purposes:

1. OpenID Connect for user authentication
2. OAuth2 for service-to-service communication

Authorization is more difficult to give general recommendations as it usually depends on business logic. Also there are no good standards in that area (XACML looks to complex for most cases and not well-suited for JSON+REST stack). In simple cases OAuth2 scopes are enough, in more complex cases authorization rules can be implemented inside diferent services separately, but managed centrally (e.g., service will register provided roles within IDM).