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 < [email protected]> 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 > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
