Hi all,
I would like to clarify the features that has been included in the
implementation of OpenID Connect Based SSO for AS.
- There is an agent API class called ‘OIDCAgent’. The requirement of the
Agent API is to have well defined methods to achieve OIDC Concepts which
can be used by a valve or a filter.
- There are four public methods in the OIDCAgent as,
1.
buildAuthenticationRequest:
Builds the authentication request and
returns it as a string.
1.
processAuthenticationResponse:
Process the authentication response and
return a bean object which can be used in the valve.
Validation of the authentication response also done inside this method by
calling private method called ‘validateAuthenticationResponse’ which
returns a boolean value.
1.
getTokenResponse:
Generate the token request, sends to the token endpoint, get the token
response, process it, validate it and returns a bean object with the
response parameters.
To validate the token response, two private methods has been implemented as,
validateTokenResponse:
Validates
the id token using the claims
validateSignature:
Validates
the signature in the id token
1.
getUserInfo:
Generates the user info request, sends it to the user info endpoint, get
the user info response, process it and return the bean object with the user
infos.
- Inside of the Agent class, a library called Nimbus
<http://connect2id.com/products/nimbus-oauth-openid-connect-sdk> is used
to implement the OIDC concepts.
- The values needed for the feature are received from the configuration
files.
- There are 2 different levels of configuration files.
1.
Server level configuration file - wso2as.xml
Values to be added:
-
Authentication Endpoint
-
Token Endpoint
-
UserInfo Endpoint
1.
Web application level configuration file - wso2as-web.xml
Values to be added as global to the applications:
-
Response type
-
Grand type
Values which are specific to web applications should be added in the
wso2as-web.xml inside the META-INF folder of the web application.
-
Client id
-
Client secret
-
Redirect URI
-
Scopes
-
Claims
- Along with the implementation of OIDCAgent, the valve class also being
implemented which is called ‘OIDCSSOValve’.
- When a http servlet request comes, the valve intercepts it and
proceeds as follow,
-
Checks whether the context level configuration is present for the
request.
-
If so, it checks for the OIDC configuration for the request.
-
Then check whether OIDC is enabled or not in the configuration
-
If there is no existing session for the request then the valve creates a
new session and call the API for build authentication request in the
OIDCAgent and redirects the browser to the identity server.
-
if the request is a response of the ‘Identity Server’, it will call the
methods from OIDCAgent to get token response and user info response and
sends request to the web application along with the access token.
-
If it is a ‘logout’ request, then it should do SLO.
- the initial request comes along with dynamical parameters which will
be set by the user. Those will get the highest preference when generating
the requests. Next preference should be given for the web application
specific configuration and last for the global level context
configuration.
- If the user defines a value for the parameter ‘state’ which is defined
in the authentication response, then it should be used in the
authentication request. Otherwise a auto generated value should be used.
- As the value of ‘state’ is used for the validation of authentication
response, it should be stored in the valve. We have decided to to store it
in a HashMap. But it can be improved in future.
For reference:
-
Specification of OpenID Connect
<http://openid.net/specs/openid-connect-core-1_0.html>
On Tue, Aug 30, 2016 at 12:50 PM, Kishanthan Thangarajah <
kishant...@wso2.com> wrote:
> Ok, so making this a general agent with well defined API's could solve
> this. We can then write a valve or a filter using this library. We will go
> ahead with the valve now and later we can include a filter also.
>
> @Abilashini, shall we first come up with the API's for this? The
> requirement here is valve or filter should be able consume APIs exposed
> from this agent library for doing OpenID Connect based requests creation,
> response validations. etc.
>
> On Mon, Aug 29, 2016 at 3:15 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Aug 29, 2016 at 2:55 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Hi Johann,
>>>
>>> Few questions I need to clarify.
>>>
>>> So the requirement here is, the app developer wants to inject some
>>> custom attributes, which cannot be predefined using the wo2as-web.xml
>>> config file, to the request before the *authentication flow* is started
>>> by the valve right?
>>>
>>> How a can filter (or any entity) identify different type of requests and
>>> inject attributes based on the type of the request? Do we have some
>>> examples (reference) on these dynamic attributes?
>>>
>>
>> That is basically the web application logic. Users can implement the
>> filter in whatever way they want to identify the requests and set the
>> scopes, claims, acr values etc. to make the request much more dynamic. In
>> real world use cases we can't have static configurations for these, even if
>> we have it at per SP level.
>>
>>
>>>
>>> On Sun, Aug 28, 2016 at 1:41 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Hi Abilashini,
>>>>
>>>> The valve approach might not be able to cater all webapp developer
>>>> requirements. Especially there are certain parameters in the OIDC request
>>>> which can be dynamic, changes from request to request, e.g. claims, scopes,
>>>> etc. During the meeting we had we decided to provide them as configuration
>>>> parameters in as_web.xml. However thinking again I don't think a webapp
>>>> developer is always able to limit himself to a constant set of values for
>>>> these parameters.
>>>>
>>>> So there must be a way for the webapp developer to provide these values
>>>> dynamically to our OIDC implementation. If we take the valve approach it
>>>> may be bit hard because webapp develop can't inject any attributes before
>>>> our valve gets executed. To do that you need to place a valve in front of
>>>> our valve by editing the catalina-server.xml.
>>>>
>>>> However if we take a filter, webapp developer can write and place a
>>>> filter before our filter gets executed and inject certain attribute values
>>>> he wants to the request. These attributes are well defined attributes in
>>>> our implementation that can give us the dynamic values the developer wants.
>>>>
>>>> So I am not totally discarding the valve approach. I think the best way
>>>> to do it would be to implement it as a standalone agent library which can
>>>> be invoked from a valve or filter or anything else which will be more
>>>> future proof.
>>>>
>>>> Also remember the implementation for state parameter should use an
>>>> extension point to store context information until the authorization
>>>> request is sent to IDP and response is received. The default implementation
>>>> could be a in-memory map, but users may extend this to implement using
>>>> session, database, distributed maps, etc.
>>>>
>>>> On Thu, Aug 25, 2016 at 6:28 PM, Abilashini Thiyagarajah <
>>>> abilash...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> OpenID Connect is an authentication layer on top of OAuth 2.0 protocol
>>>>> which is becoming more popular to be used. The idea of this project is to
>>>>> implement a valve for WSO2 AS which supports OpenID Connect based Single
>>>>> Sign On (SSO). The valve will be implemented as a global level Tomcat
>>>>> Valve.
>>>>>
>>>>> Following diagram explains the flow of Authorization code which is a
>>>>> type of openID connect.
>>>>>
>>>>>
>>>>> Parameters of the flow,
>>>>>
>>>>> Authentication Request
>>>>>
>>>>> scope, response_type, client_id, redirect_uri, state
>>>>>
>>>>> Authentication Response
>>>>>
>>>>> code, state
>>>>>
>>>>> If failed : error, state
>>>>>
>>>>> Token Request
>>>>>
>>>>> grand_type, code, redirect_uri, client_id
>>>>>
>>>>> Token Response
>>>>>
>>>>> access_token, token_type, expires_in, id_token
>>>>>
>>>>> If failed : error
>>>>>
>>>>> UserInfo Request
>>>>>
>>>>> access_token
>>>>>
>>>>>
>>>>> Description on the flow of the openID connect,
>>>>>
>>>>> When a user tries to access a webapp, the flow will be initiated.
>>>>>
>>>>> The request will be intercepted by the valve.
>>>>>
>>>>> If the web app has configured OpenID Connect, then,
>>>>>
>>>>> 1.
>>>>>
>>>>> The valve sends an Authentication Request to the Authorization
>>>>> Server by doing redirect via browser.
>>>>> 2.
>>>>>
>>>>> Authorization server will authenticates the user.
>>>>> 3.
>>>>>
>>>>> Authorization server obtains the authorization permission from the
>>>>> user.
>>>>> 4.
>>>>>
>>>>> Authorization server sends the Authentication response to the web
>>>>> app via browser and it will be intercepted by the valve.
>>>>> 5.
>>>>>
>>>>> Valve sends a token request to the Token Endpoint at Authorization
>>>>> server using the HTTP POST method and form serialization.
>>>>> 6.
>>>>>
>>>>> Token Endpoint sends Token Response for the request.
>>>>> 7.
>>>>>
>>>>> Valve sends UserInfo Request to the UserInfo Endpoint at
>>>>> Authorization Server.
>>>>> 8.
>>>>>
>>>>> UserInfo Endpoint sends UserInfo Response.
>>>>> 9.
>>>>>
>>>>> Finally the request will be sent to the webapp which was initially
>>>>> accessed.
>>>>>
>>>>>
>>>>> Functionalities of the Valve :
>>>>>
>>>>>
>>>>> 1.
>>>>>
>>>>> Send Authentication Request.
>>>>> 2.
>>>>>
>>>>> Validate the Authentication Response.
>>>>> 3.
>>>>>
>>>>> Send Token Request.
>>>>> 4.
>>>>>
>>>>> Validate the Token Response.
>>>>> 5.
>>>>>
>>>>> Send UserInfo Request of scope/claim by sending the access token.
>>>>> 6.
>>>>>
>>>>> Should support SLO
>>>>> 7.
>>>>>
>>>>> Generic error handling should be done by the valve.
>>>>> 8.
>>>>>
>>>>> When a user initiates a request, it should check whether the web
>>>>> app is configured as OpenID Connect SSO then check whether it has an
>>>>> authenticated session then it should do the redirection.
>>>>> 9.
>>>>>
>>>>> It should keep the user informations of each request as a model
>>>>> object in the request session.
>>>>>
>>>>>
>>>> Let's also think about storing this information as a request attribute.
>>>> These days usage of webapp sessions are no more a given. People sometimes
>>>> prefer using other forms of storage due to some problems with sessions.
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>>
>>>>>
>>>>> --
>>>>> T. Abilashini
>>>>> Intern
>>>>> Software Engineering
>>>>> WSO2 Inc. http://wso2.com/
>>>>> Phone +94 719248432
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regards,
>>>>
>>>> *Johann Dilantha Nallathamby*
>>>> Technical Lead & Product Lead of WSO2 Identity Server
>>>> Governance Technologies Team
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile - *+94777776950*
>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Kishanthan Thangarajah*
>>> Technical Lead,
>>> Platform Technologies Team,
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - +94773426635
>>> Blog - *http://kishanthan.wordpress.com
>>> <http://kishanthan.wordpress.com>*
>>> Twitter - *http://twitter.com/kishanthan
>>> <http://twitter.com/kishanthan>*
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+94777776950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Kishanthan Thangarajah*
> Technical Lead,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
T. Abilashini
Intern
Software Engineering
WSO2 Inc. http://wso2.com/
Phone +94 719248432
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
