Hi, There are several libraries available and we use a library called 'Nimbus' inside the agent API. What we do here is to come up with a API class which will be compatible with the WSO2 Application Server. So when a user use this extension he doesn't want to have any knowledge about the library we have used because it will be fully wrapped by the agent API.
Thanks On Fri, Oct 21, 2016 at 7:26 AM, Prabath Siriwardana <prab...@wso2.com> wrote: > 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 < > abilash...@wso2.com> 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 < >> kishant...@wso2.com> wrote: >> >>> Hi Abilashini, >>> >>> On Thu, Oct 20, 2016 at 10:23 AM, Abilashini Thiyagarajah < >>> abilash...@wso2.com> 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 < >>>> 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 >>>> >>>> >>> >>> >>> -- >>> *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 >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://facilelogin.com > > _______________________________________________ > 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
