On Wed, Mar 30, 2016 at 7:42 PM, Omindu Rathnaweera <[email protected]> wrote:
> Hi All, > > I have been working on a PoC to implement identity usecase on top of the > next gen ESB. This is to provide and update on the progress. > > For the PoC we have selected a SAML to OIDC federated login scenario. > > [image: Inline image 1] > > The sequence diagram of the federation scenario in a high level can be > found at [1] and the detailed version can be found at [2]. The > implementation is at [3]. > > Here, a service provider is represented using a sequence and the sequence > has a set of custom mediators to process and build SAML and OIDC requests > and responses. > > In a complete login flow, > > There are 2 http inbound requests to the bus. 1st request from SP with the > SAML request and the 2nd request from IDP with ID token. The requests are > distinguished by filtering from 'Referer' http header and the mediation > flow is decided upon the filter's output. > > The following complications were identified during the PoC. > > - Since there are multiple requests for a single authentication flow, > for each request a separate set of mediators should be executed. > > For example, in the SAML-OIDC scenario, if the request is from the > service provider, SAML request processor & OIDC request builder mediators > should be executed and if the request is from the IDP, OIDC response > processor & SAML response builder mediators should be executed. > > Even though for this use case, a header based filter is used, > depending on the scenario and the protocols involved, the filtering should > be changed (payload based, url parameter based). Further, selecting the > mediators based on a filter may not be feasible in a complex authentication > scenario including multiple steps and multiple options. Basically, there > should be a mechanism to continue the service provider sequence, from where > it was last stopped. > > - Need of a repository to store the request content of an > authentication flow. > > In order to build the SAML response, some content of the SAML request > is needed. Therefore, the initial SAML request should be persisted and SAML > response builder should be able to retrieve from the repository. > > Isn't this equivalent to store the request on a variable in ESB? > > - Further, the OIDC response from the IDP and the SAML request should > be correlatable. > > - Dynamically configuring an outbound endpoint. > > Few other points to be discussed are, > > - Having a single request entry point for all SPs vs. having a per > service provider request entry point. > - What's the end user's experience should be like. By end user I'm > referring an identity admin who's configuring a service provider. > > > @Prabath, Kasun: It's better to have a few more discussion to come up with > a design to overcome these issues. > > [1] - > https://drive.google.com/file/d/0BzRDbfbIaYjCcFZWbzRvTnVfdGs/view?usp=sharing > [2] - > https://drive.google.com/file/d/0BzRDbfbIaYjCdEZEZWtianJFNG8/view?usp=sharing > [3] - https://github.com/omindu/iml-poc > > Regards, > Omindu > > -- > Omindu Rathnaweera > Software Engineer, WSO2 Inc. > Mobile: +94 771 197 211 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - "lean . enterprise . middleware" Phone: +94 714897591
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
