Hi, Some of the authenticators we implement can act as second factor as well as first factor. eg:- [1]
So in the case of two factor authentication we are validating the user id from second factor against the first factor. (Most probably a claim) AFAIK currently only solution is to do two authenticators to support above use cases. Can we consider this as well in new framework? Also are we supporting backward compatibility to the components already written as extensions? [1] https://getclef.com/ On Thu, Mar 10, 2016 at 1:21 AM, Pulasthi Mahawithana <[email protected]> wrote: > Sorry, there seems to be a problem with the image. Adding it below. > > [image: Inline image 1] > > 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 >> > > > > -- > *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 > > -- Best Regards, Malaka Silva Senior Tech Lead M: +94 777 219 791 Tel : 94 11 214 5345 Fax :94 11 2145300 Skype : malaka.sampath.silva LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 Blog : http://mrmalakasilva.blogspot.com/ WSO2, Inc. lean . enterprise . middleware http://www.wso2.com/ http://www.wso2.com/about/team/malaka-silva/ <http://wso2.com/about/team/malaka-silva/> https://store.wso2.com/store/ Save a tree -Conserve nature & Save the world for your future. Print this email only if it is absolutely necessary.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
