What is the "API class which will be compatible with the WSO2 Application Server."? Is it not a servlet filter?
Thanks & regards, -Prabath On Sun, Oct 23, 2016 at 10:15 PM, Abilashini Thiyagarajah < [email protected]> wrote: > 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 <[email protected]> > 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 < >> [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 >> >> > > > -- > 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
