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
