Hi All, We have implemented a new inbound identity request model for the previous release as mainly with the new custom inbound athenticator feature. This is explained clearly in [1].
[1] http://hareendracsespace.blogspot.com/2016/06/custom-process or-with-new-identity.html Then we thought to take this same model one level higher and fulfill the inbound, local and outbound requirements that we have now. We have done a basic POC for this model with IS using OpenID Connect - SAML2 SSO federation. High level design of the core framework as follows, As the core model of this framework, we have processors, identityRequest, identityResponse and processorCordinator. This is an OSGi level service implementation that any one can use ProcessorCordinator and call process method after selecting a relevant processor according to the canHandle implementation. Following is the sequence in high level. To consume the HTTP level request by this framework, we should have HTTP Request/Response model in front of this IdentityRequestCoordinator. This is already implemented in current Inbound model and we make it more generalize as in below. As in the above diagram, when the request come to the IdentityServlet, we are using HttpIdentityRequestFactory to build the basic IdentityRequest. Anyone can extends both HttpIdentityRequestFactory and IdentityRequest to handle their own request. When processor get the IdentityResponse, HttpIdentityResponseFactory will generate the HTTP response based on IdentityResponse. In above, we have explained the framework and now we are going to use this framework and implement the AuthenticationProcessor to handle inbound and outbound request. As in above diagram, we have implemented the AuthenticationProcessor and doing validating request, authenticating and build the response. All the handler points are extensions with pre/post extensions for each handler as well. If we jump to the more detail about the AuthenticationHandler to get to know how the outbound works with this, following is the diagram. As in this implementation, we have a sequence builder as a handler and based on the sequence, authentication flow will be continue. This is will allow to run the dynamic sequence like per request based on the implementation of the AbstractSequenceBuildFactory. This is the repo location for this POC https://github.com/harsha1979/carbon-identity-framework.git branch : framework-poc Advantages of this model compared to current model are as below. 1. Zero coupling to HttpServletRequest/HttpServletResponse. Which means it will be very easy to expose the authentication framework functionalities as a backchannel API, OSGi or web service if required. 2. Multiple types of extension points to do exactly what we require. E.g. Request factories, Processors, handlers, sequence builders, authenticators, etc. Use of right OOP design patterns. 3. Extension point to build dynamic sequences (SequenceBuilder) 4. Ability to redirect from any point in the process if required. 5. Much better extension points, and object models which won't require API changes in future. 6. Single endpoint exposes all the authentication related functionality in IS. 7. No more unwanted redirections from inbound endpoints to 'commonauth' framework. This will give much better performance. 8. Very light weight framework that is decoupled with all the implementation. More of the limitations in current authentication framework are discussed in [2]. We must consider these and fix them when proceeding with this model. [2] https://wso2.org/jira/browse/IDENTITY-3391 We highly appreciate your thoughts to improve this model. *Harsha Thirimanna* Associate Tech Lead | WSO2 Email: [email protected] Mob: +94715186770 Blog: http://harshathirimanna.blogspot.com/ Twitter: http://twitter.com/harshathirimann Linked-In: linked-in: http://www.linkedin.com/pub/ harsha-thirimanna/10/ab8/122 <http://wso2.com/signature> On Thu, Mar 10, 2016 at 1:16 AM, Pulasthi Mahawithana <[email protected]> wrote: > Hi, > > Identity Server’s Authentication framework’s current implementation has > following limitations. > > > 1. When writing custom components to the framework, even to do a minor > modification, we have to write a considerable amount of code because the > interfaces are too abstract. Also extending a class at the top level will > require to have custom classes from that point. (e.g. If we extend > RequestCoordinator, we’ll most likely be required to extend > AuthenticationRequestHandler, StepBasedSequenceHandler, .. and so on) > > 2. Authentication framework is coupled to HTTP Requests and responses. > Doing API calls for back channel authentications are not possible. > > 3. There are several session management requirements which cannot be > facilitated by the existing implementation. eg. Same physical user can’t > have different sessions as users in different tenants in same browser, > cookie domain set from framework is not configurable. > > 4. Authentication framework supports only the login and logout > processes only. It can’t support any other types of interactions (eg. get > claims of already authenticated user) > > 5. Authentication framework only supports authenticators as steps in > the sequence. Need to have custom handlers also configured (such as XACML > Authorization handler) > > 6. The sequence is currently not dynamic. Need to allow more > flexibility to change it dynamically if needed (eg. We might need to > continue to next step even if some authenticator is failed) > > 7. Events are not published in the authentication framework. Also, > support for publishing the events cannot be easily implemented for certain > events. Eg. Authentication failures may be handled by either the > authenticator or by the framework, which make it harder to capture the data > for the events and make it inconsistent. > > > To address those issues we came up with the following design. > > > > > *AuthN Servlet *: Will be the endpoint for all types of requests. > Forwards the request to the Coordinator. > > *Coordinator* : Receives the Request from servlet. Then calls the > InboundRequestModelBuilder to extract the parameters(if not an API call), > Inbound processor for protocol specific processing, and Handlers for login, > logout, provisioning etc. > > *InboundRequestModelBuilder* : Accepts the HTTP request and response as > the parameters and generate InboundRequest using the HTTP request. The > InboundRequest will have the cookies, parameters and any other useful data > from the request. > > *Inbound Processor* : This will be the interface for protocol specific > processors (eg. SAML, OIDC). Will process the inbound request and return > with a FrameworkResponse which contains the statusCode (which will decide > whether to fail, redirect or continue to outbound handlers) and set of > parameters which were processed. It will also be responsible for building > protocol specific response back from the framework. > > *Handler* : Interface for the request handlers. LoginHandler, > LogoutHandler, ProvisioningHandler will be some of the default > implementations of the handler. Each handler's getOrderId() method will > decide the order of the handlers to be invoked, and with canHandle() the > handler can decide whether it’s going to handle the request or not. > > Each handler can modify the FrameworkResponse as needed and depending on > the response the Coordinator will decide whether to continue the handler > chain or to respond back (with error or redirect) > > Once the handler chain is completed the Coordinator will call the > InboundProcessor to build the protocol specific response to be responded > back. > > > Any suggestions and thoughts are highly appreciated. > > Thanks. > -- > *Pulasthi Mahawithana* > Software Engineer > WSO2 Inc., http://wso2.com/ > Mobile: +94-71-5179022 > Blog: http://blog.pulasthi.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
