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:

OIDC Core[3]
OIDC Discovery[4]
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.

End user - End user is same as the OAuth2.0 resource owner who is requested for identity information.
Relying Party(RP) - Relying Party is same as the OAuth2.0 client requiring End-User Authentication and Claims from an OpenID Provider.
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.

Authorization Endpoint - This is the endpoint in OP, where user is authenticated.
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.
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.

Authorization code (Basic)
Implicit
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.