Just a suggestion to think about: As we are introducing a completely new aspect to IS which is to handle logout requests from federated IdP, isn't it much more cleaner in the code level to have this as a completely new endpoint instead of mixing it up with the existing /commonauth endpoint? I am not saying it is wrong to do it with /commonauth endpoint. But separating this aspect will improve code structure I believe. Architecturally the /identity endpoint could also be used here without even introducing a new endpoint. We can write a new inbound authenticator to process the logout requests and build the logout responses. Though the name may not suit, semantically the idea is the same. The inbound authenticator framework has some good features around HTTP request/response processing. Something to just think about.
Regards, Johann. On Tue, Aug 13, 2019 at 5:10 PM Isanka Rajapaksha <[email protected]> wrote: > Hi All, > > I’m currently working on the “SAML Federated IdP Initiated Logout” > feature. In the Identity server implementation, we have the support for > SAML2 SP initiated logout for federated IdPs and with this feature, we will > have the capability to handle federated IdP initiated logout requests as > well. > > *Scenario:* > > Consider the following diagram *(Figure-01)* where WSO2 identity server, > SP1, and SP2 are service providers of federated IdP. Also, SP3, SP4, and > SP5 are service providers of wso2 identity server. When a user tries to > logout from the SP1, SP1 will send a logout request to the federated IdP. > Federated IdP will determine the session participants using the session > index available in the logout request. As Identity server is a session > participant, Identity Server will receive a logout request from the > federated IdP. Now Identity Server needs to handle this request, terminate > the session and response back with a valid logout response. Communication > between Identity Server and federated IdP can happen in different > bindings(Ex: POST, Redirect, SOAP), so Identity Server should able to > handle them regardless of the binding. > > > [image: Blank Diagram (11).png] > * Figure-01* > > > > *Objective:*The objective of this feature is to provide the capability to > handle federated IdP initiated logout requests. Furthermore, if service > providers of the Identity Server have enabled the IdP initiated logout > feature, Identity Server should be able to propagate the session > termination to the connected SPs. > > > *Solution:* > > In the proposed solution logout requests from the federated IdP will be > received by the “/common-auth” endpoint. Then authentication framework > will iterate through authenticators to identify the outbound authenticator > which can handle the logout request. Then the relevant authenticator will > validate the logout request and if the request is valid, it will initiate a > logout flow in the authentication framework. In this case, the framework > session identifier needs to be identified from the SessionIndex element in > the received logout request. Now, the authentication framework will > terminate the user session and if required it will send the logout requests > for the connected service providers as well. Then it will pass the > framework response to the authenticator and authenticator will build the > logout response and will send back it to the federated IdP. > > [image: Blank Diagram (9).png] > *Figure-02* > > We would like to have your feedback and suggestions in this regard. > > Thanks & regards, > Isanka > > -- > Isanka Rajapaksha | Software Engineer Intern | WSO2 Inc > (m) +94 702515205 | (e) [email protected] > > <http://wso2.com/signature> > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
