What are the other open source OIDC implementations available for Java EE servers (client side)...? and how ours different from those...?
Thanks & regards, -Prabath On Thu, Oct 20, 2016 at 4:30 AM, Abilashini Thiyagarajah < [email protected]> wrote: > Hi, > > The parameters useful after the OIDC flow will be stored in a bean object > and set as an attribute in the session of the Http Servlet Request. So it > can be used in the end point of the web application. > > On Thu, Oct 20, 2016 at 3:53 PM, Kishanthan Thangarajah < > [email protected]> wrote: > >> Hi Abilashini, >> >> On Thu, Oct 20, 2016 at 10:23 AM, Abilashini Thiyagarajah < >> [email protected]> wrote: >> >>> 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. >>> >> >> This is correct. But we need to make sure that we don't use AS config >> related classes within this agent. The agent will have its own >> classes/beans to get values for its methods. AS config related code and >> this agent related should be separated. >> >> >>> >>> - 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. >>> >>> This should be an extension point. We can use a map (as the default >> in-memory state storage) but we need to provide this as an extension point >> so that users can plug in their own extended way to store the state value. >> >> Can you also explain about how the user authenticated parameters (claims, >> attributes, userinfo attributes. etc) are passed along the valve to the >> endpoint? >> >> Thanks, >> Kishanthan. >> >>> >>> - >>> >>> >>> 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 < >>> [email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Aug 29, 2016 at 2:55 PM, Kishanthan Thangarajah < >>>>> [email protected]> 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 <[email protected]> >>>>>> 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 < >>>>>>> [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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *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 >>>>>> [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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> *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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
