Identity Delegation and Federated Authentication

What is Identity?

Identity is a generic term which identifying user and attributes of user within an electronic system. An electronic system identify a user using the information shared by the user with the electronic system. Hence identity is not what you are, it is all about what you share.

Identity and Access Management is explained in the Wikipedia as below;

“enables the right individuals to access the right resources at the right times and for the right reasons.”

As per the above statement, the role of identity solution would be to grant access to a restricted resource for an authorized individual at correct time for a valid reason.

There are main two concepts which represent basis of identity such as;

Authentication

• This is the process of validating ‘who you are’ by comparing the provided information with existing information data base of the system. E.g.:- using email address / username / unique code with password.

Authorization

• This is the process of validating whether ‘you have right to access’ the requested resource on the system.

Traditional Identity Model

In conventional systems all user identity information are held within the system itself. Due to that, maintenance of the identity information has to be conducted by system administrators which is a tedious task. Below listed maintenance activities are used to be conducted as a result of above;

• Create, Update, Delete operations of user
• Maintenance of user passwords
• User authentication and authorization logic

Above logics are common to most of the systems and due to this similar set of codes/logics are being duplicated within systems and they had to provide additional security / protection for user information complying with respective Acts.

From view-point of user, the user has to create user profiles on each system in order to consume services.

Following are the main drawbacks in the Traditional Model such as;

Multiple Passwords for One Individual

• Different systems will have different validation requirements for user details such as password policies. Remembering login information for each system will be a hassle for the end users.

Duplicate of Information

• Information of a single user will be duplicated across many systems which will cause storage and energy resource wastage.

Administration Hassle

• Identity information management will be a hassle such as user password reset, security and protection system implementation for identity information.

Identity Delegation

This is the process of outsourcing the Identity and Access Management process to third-party system avoiding identity information maintenance within the system as in traditional systems. And the user could login to a system using existing login credentials maintained with a third-party identity service provider.

There are many Delegated Identity service providers in the world such as Facebook, Twitter, Google etc.

And there are certain facts to be considered prior to select a Delegated Identity service provider such as;

• Reliability of the service
• Cost of the service
• Support service provided
• Performance and Latency of identity validation process

Variety of technologies and algorithms are available to implement Delegated Identity process and following are the popularly used in the industry such as;

1. SAML — Security Assertion Markup Language
2. OAuth 2.0 — Open Authorization
3. Open ID / Open ID Connect

SAML

SAML is an XML based markup language which is invented by OASIS Security Services community. SAML version 1.0 is release in 2001 and due to certain vulnerabilities version 2.0 is being release in 2005. SAML is mainly used to implement following;

• Web Single Sign On
• Web Single Sign Off
• Attribute Based Authentication
• Web Services Security

There are four main components available in the technology of SAML implementation such as;

(ref: http://www.codeproject.com)

Assertions

• Authentication, Attribute and Authorization information are enclosed in this section of the message

Protocols

• This defines the request and response protocols to be used to access above assertions.

Bindings

• Mapping of the SAML protocol to the standard communication protocols cuch as SAML over SOAP, SAML over HTTP is specified within bindings.

Profiles

• Combinations of above are maintained as profiles for the consumption of different business use cases.

There main three roles attached in the SAML identity and access management flow such as;

User — Looking to access protected web resource

Resource Owner — Device which has the protected resource

Identity Service Provider — Entity capable of validating user identity

The authentication process could be illustrated as in the below diagram;

1.0 Login request sent by the user to the Resource Owner to access the protected resource over HTTP

2.0 Resource Owner requires identity verification, hence Resource Owner will prepare SAML token (AuthnRequest) with resource owner registration ID with identity provider and redirect response to SAML Identity Provider (IdP)

Azure AD SAML Sample : AuthnRequest

<samlp:AuthnRequest
xmlns=”urn:oasis:names:tc:SAML:2.0:metadata”
ID=”idhwu9tynwqe54be4aaf5e482730"
Version=”2.0" IssueInstant=”2019–06–19T013:30:24.1530894Z”
xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”>
<Issuer xmlns=”urn:oasis:names:tc:SAML:2.0:assertion”>callback-url</Issuer>
</samlp:AuthnRequest>

ID (mandatory) — This is used to identify the request — response mapping and the ID should be started with a character as per the standards as in the example.

Version (mandatory) — SAML version and this is usually 2.0

IssueInstant (mandatory) — DateTime UTC value when the token is created

Issuer — This should be given when the application (resource owner) is registered with the identity provider. Generally in Azure AD, an App ID URI would be given when a consumer is registered.

3.0 IdP validate the identity of the user with provided user identity information

4.0 IdP sends the response back to the Resource Owner in encoded format where decoding algorithm is agreed between Resource Owner and IdP prior to communication.

5.0 Resource Owner decode the SAML token and validate

6.0 If the user is authorized to access the resource based on IdP response, protected resource will be granted to the user.

OAuth 2.0

OAuth is an open standard used to authorization purposes. There are two versions available such as 1.0 and 2.0 where 2.0 resolves many security vulnerabilities that exists with 1.0. Unlike SAML this is designed to communicate over HTTP/HTTPS protocol. However similar to SAML this technology enable identity and access management process delegate to third-party IdP.

There are main four roles are in the OAuth identity delegation scenario such as;

Resource Owner / User — User who is looking to access protected resource

Client / Application — Client application (interface / portal) which used deliver protected resource after identity validation.

Resource Server — Actual host of the protected resource

Authorization Server — Server which issues access and refresh tokens to access controlling

Identity and Access Management process could be illustrated as below using Oauth protocol.

1.0 (Resource Owner / User will attend access protected resource over Client Application) Client Application will create authorization code request on Authorization Server.

2.0 Authorization Server will validate to ensure identity of the user.

2.1 In case of negative response; Authorization Server will redirect login request to Resource Owner.

3.0 Resource owner will login using login credentials.

4.0 Authorization Server will validate user login credentials

5.0 (Considering success case of 4.0) Authorization Server will send authorization code.

6.0 Client Application will request to exchange the authorization code access_token

7.0 Authorization Server will return access_token and may be the refresh_token based on configuration.

8.0 Client Application will request protected resource from Resource Server using access_token

9.0 Resource Server will validate access_token with Authorization Server

10.0 (Considering success case of 9.0) Resource server will return requested protected information to the Client Application where the User could access.

access_token

• Allows user to get access to restricted data
• The token is sent as a request parameter or as a header parameter
• A limited lifetime is defined by the Authorization Server to avoid continous access using same token due to security reasons

refresh_token

• This is used to renew the Access Token when it is expired
• This is usually not sent by Authorization Server any time, this will return only upon access_token expiry due to security reasons

Advantages of OAuth :-

• Allow Cross Origin Resource Sharing such as between Client Application / Portal to Resource Server.
• Security provided for protected resources
• Could reuse the access_token to grant access to protected resources

Disadvantages of OAuth :-

• Communication is not secured if the communication is not over HTTPS
• Security risk will be there when the access_token is exposed

OpenID Connect

OpenId is a open standard and a protocol for authentication. It uses the id_token to share identity information among identity validation requested systems.

By including authorization over OpenID, OpenID Connect has been invented. Combination of OAuth 2.0 and OpenID is used to build up OpenID Connect.

There are two types of tokens which are used within OAuth 2.0 such as access_token and refresh_token. OpenID is using id_token which is based on JWT (Jason Web Token) format.

Sample format of OpenID Connect tokens;

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
“id_token”: “eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg”
“access_token”: “SlAV32hkKG”,
“token_type”: “Bearer”,
“refresh_token”: “8xLOxBtZp8”,
“expires_in”: 3600,
}

id_token

• This is a Jason Web Token where it is an open standard
• JWT is Initially design in order to communicate information between two parties securely
• In order to validate security JWT used an HMAC based asymmetric key pair (Public/Private)
• There are main three components in a JWT such as;

Header : Algorithm and Token Type : This define the algorithm used to verify the security signature of the message and the type of the token such as “JWT”

Payload Data : Payload is transferred enclosed within this including below key-value pairs;

{
“sub” : “alice”,
“email” : “alice@wonderland.net”,
“email_verified” : true,
“name” : “Alice Adams”,
“given_name” : “Alice”,
“family_name” : “Adams”,
“phone_number” : “+209 (99) 100004356”,
“profile” : “https://c2id.com/users/alice”,
“https://c2id.com/groups” : [ “audit”, “admin” ]
}

• Verify Signature

In order to validate the validity of the JWT, both sender and receiver shared a secret key between them and use that to validate message security as illustrated below.

The basic authentication flow could be illustrated over a sequence diagram as below;

1.0 User sends a request to access a protected resource

1.1 Application will redirect the user to the OpenID Connect provider (IdP)

2.0 Authorization request will be sent to Idp

2.1 IdP will return login page for the user

3.0 User will be sending login credentials

4.0 User submits login credential to IdP

5.0 IdP validates user credentials

6.0 (Considering success scenario) Upon success validation user will be redirected to the User / Browser with authorization code

7.0 Redirect to the application with authorization code

8.0 Application will send a token request to the IdP witj authorization code

9.0 Validate Application request authorization code

10.0 IdP will return token to the Application with id_token, access_token, refresh_token and other token expiry values

11.0 Grand access to the restricted resource

Advantages of OpenID Connect

Since the identity and authorization mechanism available with application server subject to an expiry period, the number of network calls will be reduced where the communication performance is enhanced.

Federated Authentication

• This is a way of interconnecting identity management solutions
• This enabled to authenticate in to an OpenID enabled system using any OpenID enabled identity credentials. Such as login in to linkedin using facebook, google etc. user credentials.
• There is a global economical advantage since duplication of information has been reduced and proper activity traceability of users.
• This will reduce the administration hassle of any OpenID Connect enabled system

Future of Identity

In future there will be many more protocols introduced to implement delegated identity. And it will be a tedious and recurring task to follow each step in the protocol at the implementation phase. To overcome this there are new frameworks introduced to automate the implementation of delegated identity protocols. Such frameworks are;

• Eclipse Higgins
• Liberty Alliance

And in the future there will be intelligent agents who gain access to the system as per the evolving artificial intelligence based technologies. And there will be separated identity mechanisms for humans such as visual and voice recognition technologies.

presentation link : youtube

~ Thisara