In this multi-part blog series for Identity and Access Management (IAM), we take a look at IAM capabilities, complexity and challenges organizations face today. We also address why assessing your IAM environment is more critical now than ever before.
Identity and Access Management Series Part 2
In this part of the blog series for Identity and Access Management (IAM), we explore Claim Based Authentication (CBA) in more detail. CBA is more complicated by implementation but is more secure than authentication mechanisms of the past.
Claim Based Authentication
Claim based identity helps us understand the federation concept we discussed earlier. Applications often referred to as the “relying party” must trust the Identity Provider and often refer to as Security Token Services (STS) (Azure AD, ADFS, Ping Identity, octa, and more) to:
- Identity provider verifies the identity of the users
- Create claims with appropriate attributes
- Sign the token with a signature which issues the credential to keep it secure
When a signed token comes back to the relying party or application, the application needs to verify if the token is intact and not tampered with, before allowing a user to access the application. The diagram below shows the basic components involved when a user starts signing into an application. It also shows how the identity provider crafts the token, which is digitally signed, for that application, and how it grants access.
In the above diagram, we introduced “Identity protocols and tokens.” Identity providers used to support federation. Fiddler is a popular and free tool that an IAM professional can use to inspect tokens and claims over the wire.
Types of Identity Protocols and Tokens They Support
Traditionally, the federation in and across enterprises uses WS-Federation and SAML-P. These protocols use tokens to store claims. Claims are attributes about the user, such as name, email, and more. These token types also vary based on the protocols used. Usually, in Identity and Access Management topics, we refer to such diagrams of identity flow on the wire as “token flow diagram.” See the image below.
WS-Federation Protocol
An industry consortium developed and released this protocol in Dec of 2006 as part of the larger WS-Security framework, which they built on the work of WS-Trust. This protocol defines two profiles.
- Active requestor profile
- Passive requestor profile
As our blog series continues, we will talk about these profiles in detail.
Token support: WS-Federation is a token agnostic protocol, and it can support SAML and JWT token.
SAML 2.0 Protocol
SAML stands for “Security Assertion Markup Language.” It is a mature protocol used in identity since 2002. The disadvantage of SAML 2.0 protocol is that it is XML based and very descriptive, so it is heavy on a wire. We mostly use SAML with SOAP, XML, and SaaS applications. It can be difficult and unsuitable for bandwidth conscious mobile users.
Token support: SAML-P issues SAML tokens.
OAuth 2.0 Protocol
OAuth 2.0 (Open Authorization Framework) is a delegation of an access protocol for authorization. In OAuth 2.0, a client accesses a protected resource (Web Service or Web API) on behalf of a user. Clients can be a public client or private client. It provides delegated authorization to API (Application programing Interfaces). OAuth 2.0, preceded by OAuth 1.0, published in April 2010. OAuth 1.0 required message signatures, which made it incredibly complex. With the release of OAuth 2.0, they removed the need for a signature and developed it with dependency on communications security.
Let us briefly talk about OAuth 2.0 protocol in detail. In the modern identity world, if you are building a new application, you should consider OAuth 2.0 and OpenID Connect protocols where possible. See the simple diagram below with two applications – App1 and App2.
OAuth 2.0 allows a user to consent to App1 having access to their resources on App2, where App2 is a Web API. As part of the consent process, App1 will declare the type of access required. The user can approve or deny access. (We see pop-ups for the consent screen many times.) If the user approves access, OAuth 2.0 issues App1 an access token. The access token proves to App2 that App1 is authorized to access a resource. Along with access-token, there is a refresh token.
OAuth 2.0 has the following four flows:
- Authorization Code Grant flow
- Implicit Grant flow
- Resource Owner Password flow
- Client credential grant flow
Token support: Code redemption for Access Token, plus Refresh Token in authorization grant flow.
OpenID Connect Protocol
OAuth 2.0 is not intended for authentication. OpenID Connect defines an Identity layer on top of OAuth 2.0, used for Authentication.
The application validates the user and provides an id_token as proof of the user’s authentication. OpenID Connect mandates a JSON web token (JWT) for the id_token.
Token support: Code redemption for Access Token, plus Refresh Token in authorization grant flow and an ID_Token.
Types of Application
Now we have talked about different types of protocols, identity providers, web apps and web APIs, and token protocol support. If we combine all components, the process looks something like the diagram below. The diagram shows how applications talk to each other irrespective of application code language. I want us to focus on the complexity involved when we migrate an on-premise application. An architect must follow all these complexities very carefully.
A few of today’s competitive Identity providers include:
Cloud:
- Microsoft Azure Active Directory
- Okta
- OneLogin
- JumpCloud
- Oracle Identity Management
- AWS Directory Service
- Amazon Cloud Directory
- Apache Directory
- Social Identity providers (Google, Facebook, Twitter, Amazon)
On-Premise:
- Microsoft ADFS (Active Directory Federation Services)
- Ping Identity
- Site Minder
Note: On-premise IDPs listed above can be in any cloud with IaaS implementation.
In this blog, we discussed CBA and how hybrid identity, different protocols, and tokens play such an important role in authentication and authorization for different types of applications. In our next blog, we will introduce Microsoft’s Identity stack, take a deep dive into different identity components, and understand its complexity even further.
