+1. The features that are lined up for 5.3.0 also indicate this framework is this enough to support a wide range of capabilities as extensions. So we need to remove the work "authentication" from it.
On Fri, Mar 18, 2016 at 1:21 PM, Prabath Siriwardana <[email protected]> wrote: > Yet to go through this in full details.. But shall we rename this to > identity-kernel (instead of authn framework) ? Basically the objective > here would be to build a thin kernel, where the functionality will be added > by extensions... just like in the Maven architecture... > > Thanks & regards, > -Prabath > > 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 >> > > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://blog.facilelogin.com > http://blog.api-security.org > -- 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
