On Wed, Feb 7, 2018 at 2:33 PM, Malithi Edirisinghe <[email protected]> wrote:
> > > On Wed, Feb 7, 2018 at 2:32 AM, Johann Nallathamby <[email protected]> > wrote: > >> It is in fact an inbound connector. So +1 to use the inbound framework >> and write a InboundProcessor to process this request. This way we can have >> an abstract FederatedIdPInitiatedLogoutProcessor (you may come up with a >> different name) that will handle the logout specific logic in >> authentication framework and extend it to multiple protocol specific >> processors which will handle protocol specific logout logic. >> > > Will we need a processor in the framework. Rather, I think there should > be a service in framework for session related operations like terminate > session, check if there's a valid session etc. > The protocol specific processor will handle requests and call the > framework service for session termination. Upon the specific operation in > framework service, framework will make sure to trigger other operation > specific tasks. For example, upon session termination trigger the session > termination event, do cleanups etc. > Introduction, of such a service will be useful for many other use cases I > think. For example, extend framework session, terminate session upon > critical events and all sub operations can be triggered centrally. > WDYT? > +1. That should be the ideal approach. > > >> Whether it should come inside identity-inbound-auth-saml or >> identity-outbound-auth-samlsso, I think will have to go with what the >> majority feels, because this use case is a hybrid between both, and the >> current naming convention of repos didn't take this into consideration when >> originally naming it. It can be argued both ways, >> 1. Since this is an inbound request to IS, it should go under >> identity-inbound-auth-saml >> 2. Since this is a dealing with the session between IS and federated IdP, >> and all the IdentityProvider module dependencies are in >> identity-outbound-auth-samlsso, and since authentication between SP - IS >> and IS - IDP should be decoupled, it should go under >> identity-outbound-auth-samlsso. >> >> Both the above seem to have equal amount of convincing power to me :). >> Technically I would prefer going with 2 above, accepting the fact that >> "outbound" part in the naming is not the best, because we didn't consider >> such use case in the begining and hoping one day we will rename the repo to >> be more accurate :). >> >> Regards, >> Johann. >> >> On Tue, Feb 6, 2018 at 11:47 PM, Hasintha Indrajee <[email protected]> >> wrote: >> >>> According to the analysis, it seems like logout requests from SPs and >>> logout requests from IDPs look similar. @Kanapriya, were you able to skim >>> through specs and see whether there are differences ?. >>> >>> Also on the other hand when we have a look towards our new framework, >>> this looks more like an inbound connector because the request is initiated >>> from a third party caller. Hence it's more inbound as per our framework. >>> WDYT ?. Also if we are to follow this approach we need to avoid going >>> through loops. >>> >>> On Tue, Feb 6, 2018 at 5:09 PM, Kanapriya Kuleswararajan < >>> [email protected]> wrote: >>> >>>> Hi All, >>>> >>>> For the POC [1], I have registered a new servlet in >>>> identity-outbound-auth-samlsso authenticator and try out the FIDP initiated >>>> logout flow by removing the session id which is associated with the earlier >>>> login. >>>> >>>> Now I have tried to move the POC [1] code to support with the new >>>> identity framework. >>>> >>>> Here, we have a concern that whether we need to move the code to the >>>> *identity-inbound-auth-saml* or *identity-outbound-auth-samlsso*. >>>> >>>> IMO, we need to handle the logout request which is initiated by FIDP >>>> inside identity-inbound-auth-saml. Please find the reasons for that : >>>> >>>> - Generally, whenever the request comes to IS from External system, >>>> it will be handle by the Inbound flow (identity-inbound-auth-saml). >>>> - I have configured IS with two service providers (Travelocity, >>>> Avis) and try out the logout flow. >>>> - Where I'm able to see the SAML Logout Request which is exactly >>>> same as SAML Logout Request which is initiated by FIDP. >>>> - Since both SAML Logout Request are same, we can move code to >>>> identity-inbound-auth-saml. >>>> >>>> Appreciate your thoughts on this. >>>> >>>> [1] Federated IdP Initiated Logout >>>> >>>> Thanks, >>>> Kanapriya >>>> >>>> Kanapriya Kuleswararajan >>>> Software Engineer >>>> Mobile : - 0774894438 <077%20489%204438> >>>> Mail : - [email protected] >>>> LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/ >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> >>>> >>> >>> >>> -- >>> Hasintha Indrajee >>> WSO2, Inc. >>> Mobile:+94 771892453 <+94%2077%20189%202453> >>> >>> >> >> >> -- >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile: *+94 77 7776950* >> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >> <http://www.linkedin.com/in/johann-nallathamby>* >> Medium: *https://medium.com/@johann_nallathamby >> <https://medium.com/@johann_nallathamby>* >> Twitter: *@dj_nallaa* >> > > > > -- > > *Malithi Edirisinghe* > Associate Technical Lead > WSO2 Inc. > > Mobile : +94 (0) 718176807 > [email protected] > -- *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile: *+94 77 7776950* LinkedIn: *http://www.linkedin.com/in/johann-nallathamby <http://www.linkedin.com/in/johann-nallathamby>* Medium: *https://medium.com/@johann_nallathamby <https://medium.com/@johann_nallathamby>* Twitter: *@dj_nallaa*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
