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.<\/p>\n
Claim Based Authentication<\/h2>\n
Claim based identity helps us understand the federation concept we discussed earlier. Applications often referred to as the \u201crelying party\u201d must trust the Identity Provider and often refer to as Security Token Services (STS) (Azure AD, ADFS, Ping Identity, octa, and more) to:<\/p>\n
- \n
- Identity provider verifies the identity of the users<\/li>\n
- Create claims with appropriate attributes<\/li>\n
- Sign the token with a signature which issues the credential to keep it secure<\/li>\n<\/ul>\n
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.<\/strong> 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.<\/p>\n
![\"CBA](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/12\/IAM2-Image-1.png\")
<\/a><\/p>\nIn the above diagram, we introduced \u201cIdentity protocols and tokens.\u201d Identity providers used to support federation. Fiddler<\/a> is a popular and free tool that an IAM professional can use to inspect tokens and claims over the wire.<\/p>\n
Types of Identity Protocols and Tokens They Support<\/h2>\n
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 \u201ctoken flow diagram.\u201d<\/strong> See the image below.<\/p>\n
![\"CBA](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/12\/IAM2-Image-2.png\")
<\/a><\/p>\nWS-Federation Protocol<\/h4>\n
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.<\/p>\n
- \n
- Active requestor profile<\/li>\n
- Passive requestor profile<\/li>\n<\/ol>\n
As our blog series continues, we will talk about these profiles in detail.<\/strong><\/p>\n
Token support<\/u>:<\/strong> WS-Federation is a token agnostic protocol, and it can support SAML and JWT token.<\/p>\n
SAML 2.0 Protocol<\/h4>\n
SAML stands for \u201cSecurity Assertion Markup Language.\u201d 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.<\/p>\n
Token support:<\/u> SAML-P issues SAML tokens.<\/p>\n
OAuth 2.0 Protocol<\/h4>\n
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.<\/strong><\/p>\n
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 \u2013 App1 and App2.<\/p>\n
![\"CBA](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/12\/IAM2-Image-3.png\")
<\/a><\/p>\nOAuth 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<\/strong>. The access token proves to App2 that App1 is authorized to access a resource. Along with access-token, there is a refresh token<\/strong>.<\/p>\n
OAuth 2.0 has the following four flows:<\/p>\n
- \n
- Authorization Code Grant flow<\/li>\n
- Implicit Grant flow<\/li>\n
- Resource Owner Password flow<\/li>\n
- Client credential grant flow<\/li>\n<\/ul>\n
Token support:<\/u> Code redemption for Access Token, plus Refresh Token in authorization grant flow.<\/p>\n
OpenID Connect Protocol<\/h4>\n
OAuth 2.0 is not intended for authentication. OpenID Connect defines an Identity layer on top of OAuth 2.0, used for Authentication.<\/p>\n
![\"CBA](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/12\/IAM2-Image-4.png\")
<\/a><\/p>\nThe application validates the user and provides an id_token as proof of the user\u2019s authentication. OpenID Connect mandates a JSON web token (JWT) for the id_token.<\/p>\n
Token support:<\/u> Code redemption for Access Token, plus Refresh Token in authorization grant flow and an ID_Token.<\/p>\n
Types of Application<\/h2>\n
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.<\/strong> 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.<\/p>\n
![\"CBA](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/12\/IAM2-Image-5.png\")
<\/a><\/p>\nA few of today\u2019s competitive Identity providers include:<\/strong><\/p>\n
Cloud:<\/a><\/h4>\n