On Thu, Aug 10, 2017 at 12:28 PM, Johann Nallathamby <joh...@wso2.com>

> 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]
> I think this can be further simplified. At least it's kinda confusing me.
> E.g. there are no two components as OpenID Listener and OpenID Logout
> Handler I think. Was it done intensionally? The handler will be basically
> the listener, which will listens to Logout events and will handle the
> single logout of OpenID Connect service providers. Similarly for SAML and
> WS-Federation. So the pink diamonds and rectangles below will merge as one
> box I feel.

So, each inbound authentication component, has a logout endpoint which will
invoke the logout mechanism. Then they will have a listener or event
handler implementation which listens for the logout event initiated from
the framework in this case, which will again invoke the same logout
mechanism. So, IMO, the logout mechanism and the invocation should be
decoupled, and I feel this is fine.

> What are the roles of AuthnDataPublisher and SLOEventHandler? I was
> thinking that AuthnDataPublisher is the one responsible of publishing
> events, and that is already happening in the framework. Is it not? If that
> was the case we don't need to do any modifications to the framework. All
> that Sugirjan has to write are the event handlers in each inbound
> authentication component to handle the single logout.

There is an AuthnPublisher implemented in framework and it's a proxy. The
proxy invokes the set of publishers registered. And, those publishers have
different publish mechanisms like wiring to files, firing events, etc.  So
the SLOEventHandler here, should actually be an implementation of such a
publisher. IMO, we have to define the contract among this publisher and the
set of listeners or event handlers in each inbound authentication component.

@Hasintha: your inputs please.
> Regards,
> Johann.
> We would like to have your feedback and suggestions in this regard.
>> Thanks.
>> Regards,
>> *R. Sugirjan*
>> Software Engineering - Intern | WSO2
>> Email:  sugir...@wso2.com
>> Mobile: +94768489892 <+94%2076%20848%209892>
>> <http://wso2.com/signature>
> --
> Thanks & Regards,
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
> Mobile - *+94777776950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*


*Malithi Edirisinghe*
Associate Technical Lead
WSO2 Inc.

Mobile : +94 (0) 718176807
Architecture mailing list

Reply via email to