Skip to end of metadata
Go to start of metadata

Project Background

OIDC : OpenID Connect

OpenID Connect[1] is an authentication protocol based on OAuth2.0[2] authorization protocol. There are three main implementation for OIDC. There are:

  1. OIDC Core[3]

  2. OIDC Discovery[4]

  3. OIDC Dynamic client registration[5]


According to the above diagram OIDC Core is the minimal requirement for OIDC protocol. This proposal is based on the implementation of the OIDC Core(Basic and Implicit profiles)

OIDC Basic Components


There are three participants that engage in OIDC message passing.

  1. End user - End user is same as the OAuth2.0 resource owner who is requested for identity information.

  2. Relying Party(RP) - Relying Party is same as the OAuth2.0 client requiring End-User Authentication and Claims from an OpenID Provider.

  3. OpenID Provider(OP) - OpenID provider is same as the OAuth2.0 Authorization Server that is capable of authenticating the End-User and providing claims to a Relying Party about the Authentication event and the End-User.


Another key concept is ID_Token. ID_Token is like an identity card. Using this token, client can get some claims about the end user. This is represented as a JSON web token (JWT).

There are three main endpoints that are used for user delegation.

  1. Authorization Endpoint - This is the endpoint in OP, where user is authenticated.

  2. Token Endpoint - This is the end point used to generate an ID_Token and access token from the code generated at authorization endpoint for the client.

  3. Userinfo Endpoint - From this endpoint user informations or claims are sent to the client. For this a valid access token must be provided to the OP.


OIDC Request Flow


The below diagram illustrates the high level request passing that happens in OIDC.


First the RP will send an authentication request for the OpenID Provider(OP). Then OP will redirect the end-user to an authentication page. Then OP will authenticate the end-user and will obtain authorization. OP will send an access token and ID token to the RP. RP can send back the access token to OP’s userinfo endpoint and request user claims. Then OP can provide user claims back to RP.

There are three main flows in OIDC to request tokens.

  1. Authorization code (Basic)

  2. Implicit

  3. Hybrid.

This proposal only explains the implementation of first two flows.

Proposed Approach

Sequence Diagram : OIDC Basic Flow



For the every request and response made in this flow there should be request and response validations. For the implementation [3], [6], [7] must be used.



Sequence Diagram : Implicit Flow





Estimated Schedule



Milestone

Title

Start Date

End Date

Achievement

GSOC

Community Bonding

23/04/2018

13/05/2018


M1

Researching and ground work

14/05/2018

20/05/2018

Gather required knowledge to proceed

M1.1

Understanding Sling Authentication implementation

M1.2

Designing the architecture for Sling OIDC implementation

M2

Development

21/05/2018

10/06/2018

Authorization request

M2.1

Obtaining configuration information about the OpenID Provider using Discovery flow.

M2.2

Preparing an Authentication Request containing the desired request parameters

M2.3

Sending the request to the Authorization Server

M2.4

Testing

GSOC

Mid Evaluations 1

11/06/2018

15/06/2018


M3

Development

16/06/2018

08/07/2018

Access Token and ID Token

M3.1

Sending the code to the     Token Endpoint to receive an Access Token and ID Token in the response.

M3.2

Validating the tokens and retrieves the End-User's Subject Identifier.

M3.3

Validating requests

M3.4

Testing

GSOC

Mid Evaluations 2

09/07/2018

13/07/2018

Authenticated user information

M3.4

Send the access token to userinfo endpoint.

M3.5

Store users and claims

M3.6

Testing

M4

Code Reviews

21/07/2018


Improve code quality

M5

Documentation

01/08/2018

05/08/2018

OIDC documentation for Sling

M6

Finalizing and submitting

06/08/2018

14/08/2018

Deliverables


Project End Deliverables

Following are identified as end deliverables for the proposed project.

  • Implementing OIDC authentication handler for Apache Sling

    • Authentication request

    • Require Access Token and ID Token from OpenID Provider

    • Validate Tokens

    • Get authenticated users.

    • Save user claims.

  • Documentation



Personal Information

Name : Hasini Dilanka Witharana

Email : hasinidilanka@gmail.com/ hasini.14@cse.mrt.ac.lk

Blog : https://medium.com/@hasiniwitharana

Github : https://github.com/hasinidilanka

LinkedIn : https://www.linkedin.com/in/hasini-witharana-185785109/

University : University of Moratuwa, Sri Lanka

Field of Study: Computer Science and Engineering.

I am Hasini Witharana, final year undergraduate of University of Moratuwa. Within the past few years I have been engaged in several academic and non-academic projects. During my internship, I worked on a project related to OpenID Connect. My task was to get the OIDC certification for  an Identity server. That project helped me a lot to understand the OIDC specifications and implementations. I engaged with OIDC community to clear the doubts about the implementations as well.

I believe this project will be a perfect opportunity for me to get familiarized more with OpenID Connect while implementing an authentication handler of Apache Sling.


References

[1] - http://openid.net/connect/

[2] - https://oauth.net/2/

[3] - http://openid.net/specs/openid-connect-core-1_0.html

[4] - https://openid.net/specs/openid-connect-discovery-1_0.html

[5] - http://openid.net/specs/openid-connect-registration-1_0.html

[6] - http://openid.net/specs/openid-connect-standard-1_0-15.html

[7] - http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

[8] - https://openid.net/specs/openid-connect-basic-1_0.html






















  • No labels