Hi!

Single logout is interesting beast, so there is no quick answer.

If you are interested in all parts, continue reading. If you just need a quick answer, skip till the end of this post.

How SLO works

To successfully perform SLO, two flows need to be involved:

• When logout is initiated by application - Service Provider (SP) initiated logout
• When logout is initiated by Identity Provider - Identity Provider (IdP) initiated logout

SLO flow (simplified)

1. The end-user chooses to log out in application.
2. The application ends the user’s session and redirects the user to Identity Provider.
3. Identity provider logs out local session and requests logout from all applications this user has logged in before.

In SAML world, application must support both sending request for logout to IdP (sending <samlp:LogoutRequest> in SP Initiated Logout) and responding to logout requests sent from IdP (responding to <samlp:LogoutRequest> with <samlp:LogoutResponse> in IdP Initiated Logout).

In OpenID Connect world, application must support:

1. Service Provider initiated logout by implementing OpenID Connect RP-Initiated Logout 1.0 (openid.net/.../openid-connect-rpinitiated-1_0.html)
2. Identity Provider initiated logout by implementing OpenID Connect Front-Channel Logout 1.0 (openid.net/.../openid-connect-frontchannel-1_0.html)

(there is also OpenID Connect Back-Channel Logout, but it is not supported by AM).

Now back to your case.

When you started logout on SAML application, SAML application triggered Service Provider (SP) initiated logout towards AM (step #2 in diagram). In next step (#3 in diagram) AM should trigger Identity Provider (or in OIDC world OpenID Provider - OP) initiated logout by implementing OpenID Connect Front-Channel Logout 1.0, but obviously does not, probably because of missing configuration on AM side.

When you tried to logout from OpenID Connect application, application triggers Service Provider (or in OIDC world Relying party - RP) initiated logout by implementing OpenID Connect RP-Initiated Logout.

Bhabani sankar Patra said:

so is there any further configuration is required to achieve this single logout between applications?

Check if you have configured application's Front-Channel Logout URI on OAuth client (https://www.microfocus.com/documentation/access-manager/5.0/admin/oauth_client_reg.html). This will tell AM what URL to call to trigger logout from OpenID Connect application.

Regarding a blank screen after calling nidp/oauth/v1/nam/end_session URL, in my experience this happens only if there is no user session on NAM (you said you have logged out of SAML application first, which also invalidated session on NAM).

I also think this is a bug in AM, since documentation clearly states that in that case user should be redirected either to post_logout_redirect_uri or IDP login page (if post_logout_redirect_uri is not specified):

From documentation www.microfocus.com/.../t4ebzks5bvnc.html:

Kind regards,

Sebastijan

The blank screen is a problem that has already been reported to Micro Focus. I asked our partner to share a defect ID with me. As soon as I have it I will share it.

If a user has a session on the Identity Provider and it expires (for example, due to a timeout). And the user then initiates a logout on an application which is federated using OpenID Connect, the application can initiate a logout to the Identity Provider. Access Manager will show a blank screen to the client.

An additional problem is that the Access Manager SAML2.0 Single Logout implementation completely ignores the OpenID Connect logout implementation. This reinforces the problem described above.

We have an environment with hundreds of federations (both SAML2.0 and OpenID Connect) and this problem is preventing us from upgrading to version 5.0.x

 Sebastijan Sef 

A few comments on your response:

1) To my knowledge, the OASIS SAML2.0 specification does not distinguish between Single Logout initiated by Identity Provider and Service Provider, but only describes the flow. So it can be initiated by all parties. And somewhat more "complex" situations can arise when a user is signed up with multiple Service Providers or when using the profile extension mentioned below.

2) You describe that the application deletes the user session and then redirects the user to the Identity Provider. This is only the case with an 'Asynchronous Single Logout Profile Extension'. In all other cases, the Service Provider must wait for the response from the Identity Provider (LogoutResponse) before invalidating the session. Otherwise, a situation arises where the session on the Identity Provider may not be revoked, something you need to act on as a Service Provider (through an error message to the client). If the user is already logged out by then, this might imply otherwise.

3) The above also applies to the session on Identity Provider when it receives an error message from another Service Provider (via a LogoutResponse). In any case, my experience is that it makes SAML2.0 Single Logout implementation particularly vulnerable to errors.

Hi Tom!

Regarding your comments, you are absolutely right. My explanation was simplified intentionally, to better present what is most of the time forgotten, which is that logout can happen both on SP (RP) side and IDP (OP) side. And as a consequence, to have SLO working, BOTH flows must be supported and configured on ALL components.

For example if I would properly state that local logout (either SP/RP or IDP/OP) happens only after receiving response from other parties, diagram would have probably 3 or more times more steps.

So let me add a note to my previous post.

Regarding front channel logout defect, any information you have and are allowed to share is appreciated

Kind regads,

Sebastijan

Sebastijan Sef 

My apologies for the late response, I probably overlooked a notification. The Defect ID is OCTCR56A320017.

In my opinion there are at least two issues in the implementation of RP-initiated logout for OIDC in Access Manager 5:

- A user initiates a logout from a Relying Party but the session on the OP no longer exists. Access Manager then displays a blank screen.

- A user initiates a SAML2.0 Single Logout. The process Access Manager now kicks off does not cause the user to be logged out on federated RP’s. If the user initiates a logout request from a RP it will trigger the issue as described above.

There are of course more scenarios to think of (such as a local logout on AM) that could also trigger this issue.

I am eager to see what solution Micro Focus comes up with. In the absence of a permanent solution I hope for the introduction of a global setting to disable RP-initiated logout because many OIDC applications use the well known endpoint (/.well-known/openid-configuration) which now advertises support for RP initated logout.

An addition to the above:

If Micro Focus wants to achieve a protocol-independent user experience with Access Manager, it must also implement it protocol-independently.

In other words, if I log out on a SP/RP then I must either log out on all SP/RP's or only the one thats initiated it. This of course only applies to SP/RP's that have implemented (single) logout.

Ensure that the session management settings are correctly configured for both applications. The session management should be able to handle the logout requests and terminate the user session across all applications in the same session.

Verify that both your OAuth and SAML applications snaptik single logout. Ensure that the applications are configured correctly to initiate the logout process when a user logs out from one of the applications.

The topic starter is experiencing a bug and design flaw that have already been reported to Micro Focus.

You talk about session management, do you mean the settings related to timeout? Because getting these in sync between different SP/RP's is a utopia. The local session application A != local session application B.

And the same goes for ending a session due to inactivity (reaching the set timeout value on the SP/RP). How are you going to use frontchannel bindings to notify the IdP/OP that the session has to be ended there as well? The timeout on the IdP/OP can be influenced by the fact that the user has logged into another SP/RP's.

Maybe I am missing the broad picture so if I am wrong I would like to hear it 

Just for reference, we got a Knowledge article regarding "blank screen" bug:

portal.microfocus.com/.../KM000018325

Thanks for the FYI!