On Mon, Aug 14, 2017 at 10:27 PM, Harsha Thirimanna <hars...@wso2.com> wrote:
> > > On Mon, Aug 14, 2017 at 6:37 PM, Piraveena Paralogarajah < > pirave...@wso2.com> wrote: > >> Hi Maninda, >> >> In OpenID Connect, there are three ways for SLO. >> >> 1. OIDC Session management (see spec >> <http://openid.net/specs/openid-connect-session-1_0.html>) >> 2. OIDC Front-channel logout (see spec >> <http://openid.net/specs/openid-connect-frontchannel-1_0.html>) >> 3. OIDC Back-channel logout (see spec >> <http://openid.net/specs/openid-connect-backchannel-1_0.html>) >> >> In federated authentication, WSO2-IS will act as an RP and also it will >> act as an OP to the downstream RPs and logout the the downstream >> logged-in sessions. You can refer these specifications. >> But Facebook is not an OpenID provider. It uses its own OpenID-like >> system called Facebook connect. You can refer this stackoverflow >> question [1] >> <https://stackoverflow.com/questions/1827997/is-facebook-an-openid-provider> >> >> >> Regards, >> Piraveena >> >> *Piraveena Paralogarajah* >> Intern- Software Engineering | WSO2 >> *Email *: pirave...@wso2.com >> *Mobile* : +94776099594 <+94%2077%20609%209594> >> <http://wso2.com/signature> >> >> On Mon, Aug 14, 2017 at 5:37 PM, Maninda Edirisooriya <mani...@wso2.com> >> wrote: >> >>> Hi Sugirjan, >>> >>> How the SLO works with sessions logged in with federated authentication? >>> For example if a user has logged in with Facebook authentication how that >>> user be logged out from the Authentication framework when the user is >>> logged out from Facebook? Does OIDC has some spec to notify the WSO2 IDP >>> that the Facebook was logged out? >>> >>> Thanks. >>> >>> >>> *Maninda Edirisooriya* >>> Senior Software Engineer >>> >>> *WSO2, Inc.*lean.enterprise.middleware. >>> >>> *Blog* : http://maninda.blogspot.com/ >>> *E-mail* : mani...@wso2.com >>> *Skype* : @manindae >>> *Twitter* : @maninda >>> >>> On Thu, Aug 10, 2017 at 5:53 PM, Sugirjan Ragunaathan <sugir...@wso2.com >>> > wrote: >>> >>>> Hi Kasun, >>>> >>>> On Thu, Aug 10, 2017 at 12:11 PM, KasunG Gajasinghe <kas...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> Can you list possible customer usecases on why they want to use this? >>>>> >>>> >>>> The main usecases are >>>> >>>> 1. If user using multiple applications which supports different >>>> authentication protocols on same browser session and user gets logout from >>>> one application, then he will be automatically logged out from all other >>>> applications. For example if user user use SAML based application and OIDC >>>> based Application on same browser session and if he logs out from SAML >>>> based application then automatically he will be logged out from OIDC based >>>> application. >>>> Currently Identity Server supports only for Cross protocol Single Login >>>> only. >>>> >>>> 2. If user administrator wants to logout from all the applications >>>> which are emerged with Identity Server on same browser session, he can do >>>> force logout from all those applications without regard to authentication >>>> protocols that are supported. For example if any security breaches is >>>> happened and admin user want to logout from all the applications he can >>>> initiate a force logout request for them. >>>> >>>> >>>> On Thu, Aug 10, 2017 at 11:47 AM, Sugirjan Ragunaathan < >>>> sugir...@wso2.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Currently I’m working on a project 'Cross protocol single logout'. >>>>> WSO2 Identity Server provides Single LogOut over applications, >>>>> participating on the same session over the same authentication protocol >>>>> and >>>>> Single SignOn over the different protocols. >>>>> >>>>> [image: 1.png] >>>>> >>>>> Objective: >>>>> >>>>> Design and provide a solution to support cross protocol SLO >>>>> >>>>> Problem : >>>>> >>>>> WSO2 Identity Server supports multiple applications which are using >>>>> different authentication protocols. It does not provide cross protocol >>>>> Single Logout. For example, Assume that you are using SAML based >>>>> application and OIDC based application is same browser session. when you >>>>> logout from a SAML based application it will only log you out from other >>>>> SAML applications not from OIDC based application with the same session. >>>>> >>>>> Solution: >>>>> >>>>> The proposed solution for this problem is implementing a common event >>>>> handler over different protocols. When a session is terminated because of >>>>> user logout, an event should be published to invoke the ‘SLO Event >>>>> Handler’.So 'SLO Event Handler' notifies all the inbound authenticators >>>>> and >>>>> the authenticators handle respective logout actions. In order to >>>>> listen the logout event, all the respective authenticators have to be >>>>> subscribed in the ‘SLO event handler’ and have own separate event handlers >>>>> to trigger the logout for their registered applications. >>>>> >>>>> [image: SolutionArchi.png] >>>>> >>>>> >>>>> We would like to have your feedback and suggestions in this regard. >>>>> >>>> > > +1 for this approach and while triggering this subscribed events, shall we > have a API to call to send SLO request, because it may be useful like, when > we disable a user from admin console or using API, we can trigger that SLO > API for that user and terminate both IS session and the client sessions as > well. > Yes we can expose an API such that the implementation will be another event publisher > And how do we handle this SLO with a federated IDP as well. > > ex: SP1 -> inbound OIDC and IDP resident. > SP2 -> inbound OIDC and IDP federated. > > If SP1 client send logout request, then SP1 and SP2 client will get logout > request because of this subscription model. Don't we need to send logout to > federated IDP of SP2 as well ? > I don't think so. Because, if we take login, logged into the resident IdP does not mean that you are also logged into the federated IdP as well. So if you try to login to SP2 in above case, you will get the login page from the federated IdP. So, should it be that logging out from the resident IdP only, should log out the user from the federated IdP as well. Which is the case you have mentioned above. I think, we should notify only the session participants of the current IdP session. > > >> >>>>> Thanks. >>>>> >>>>> Regards, >>>>> *R. Sugirjan* >>>>> Software Engineering - Intern | WSO2 >>>>> >>>>> Email: sugir...@wso2.com >>>>> Mobile: +94768489892 <076%20848%209892> >>>>> <http://wso2.com/signature> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc. >>>> email: kasung AT spamfree wso2.com >>>> linked-in: http://lk.linkedin.com/in/gajasinghe >>>> blog: http://kasunbg.org >>>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813 >>>> >>>> >>>> Thanks. >>>> >>>> Regards, >>>> *R. Sugirjan* >>>> Software Engineering - Intern | WSO2 >>>> >>>> Email: sugir...@wso2.com >>>> Mobile: +94768489892 <076%20848%209892> >>>> <http://wso2.com/signature> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > -- *Malithi Edirisinghe* Associate Technical Lead WSO2 Inc. Mobile : +94 (0) 718176807 malit...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
