Implement OpenID Connect Back-Channel Logout 1.0

[shubjit]

Description

Implement OpenID Connect Back-Channel Logout 1.0 for the Liberty OP, RP, and oidcLogin.

The Liberty OP and RP need to implement OpenID Connect Back-Channel Logout 1.0 for an OP configured with SAML IdP to notify the RP(s) of a logout at the SAML IdP and for the RP(s) to receive such notifications.

START of historical context:
Describe the bug
Logout from SAML IDP does not send notifications back to RPs via Liberty OIDC Provider.

We have configured an IBM product set (RP) with a Liberty OIDC provider which further delegates Authentication to a SAML IDP. We understand that there are two logout apis in LIberty OP. If the logout is initiated by our RP it seems to send the redirects and all applications within our RP is logging out.

The issue we are facing is, if logout is initiated outside RP (another application connected to SAML IDP or IDP itself), a different logout api in OP seems to be invoked, which is not triggering our RP logout.

Steps to Reproduce

We setup a Sample Environment with snoop to test this using the following URL
https://www.ibm.com/docs/en/was-liberty/base?topic=uoc-getting-started-configuring-openid-connect-provider-client-in-liberty

• We configured "snoop" application on a Liberty server as RP (Liberty_RP)
• We Configured a Liberty Server as an OP (Liberty_OP) and configured the OP to redirect to a SAML IDP
  https://www.ibm.com/docs/en/was-liberty/nd?topic=liberty-configuring-saml-web-browser-sso-in
• We also configured snoop application on the Liberty_OP

Testing:

• Login to https://liberty_RP/snoop

• It is redirected to SAML IDP to Login as a user (Page is displayed post Login)

• Login to https://liberty_OP/snoop , this page is redirected to SAML IDP and via SSO it is already logged in

• Logout at the SAML IDP

• As per logs, Liberty_OP is receiving the Logout requests from SAML IDP

• Reload the https://liberty_OP/snoop page and it is redirected to the SAML IDP

Issue: Reload the https://liberty_RP/snoop page and the session is still active

Expected behavior*

When a logout is initiated at the SAML IDP level, Liberty OP is receiving the Logout request and it should notify the RP and RP applications session should end

Diagnostic information:

• Liberty Version: 20.0.0.6 , tested on 21.0.0.6 as well

Additional context
Add any other context about the problem here.

END of historical context.

---

Documents

When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.

• Aha: Externally raised RFE (Aha)
• UFO: https://ibm.box.com/s/g4db0qsrh7wt8x7c8lig748ovhg94vtf
  • Set the Box link to be publicly accessible, with a long expiration (10 years)
    • click "Share" > select "People with link" > click "Link Settings" > under "Link Experation" select "Disable Shared Link on" > set an experation date ~10 years into the future
    • If you lack permissions, contact OpenLiberty/release-architect
• FTS: Feature Test Summary for OIDC Back-Channel Logout #20044
• Beta Blog: BETA BLOG - Back-channel logout support for OpenID Connect clients and servers #27362
• GA Blog: GA BLOG - Back-channel logout support for OpenID Connect clients and servers #27477

---

Process Overview

• Prioritization
• Design
• Implementation
• Legal and Translation
• Beta
• GA
  • Focal Point Approvals
• Other Deliverables

General Instructions

The process steps occur roughly in the order as presented. Process steps occasionally overlap.

Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").

Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.

If you need assistance, reach out to the OpenLiberty/release-architect.

Important: Labels are used to trigger particular steps and must be added as indicated.

---

Prioritization (Complete Before Development Starts)

The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.

Prioritization

• Feature added to the "New" column of the Open Liberty project board
  • Epics can be added to the board in one of two ways:
    • From this issue, use the "Projects" section to select the appropriate project board.
    • From the appropriate project board click "Add card" and select your Feature Epic issue
• Priority assigned
  • Attend the Liberty Backlog Prioritization meeting

---

Design (Complete Before Development Starts)

Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.

Design Preliminaries

• UI requirements identified. (Owner and UI focal point)
• ID requirements identified. (Owner and ID focal point)
  • Refer to Documenting Open Liberty.
  • Feature Owner adds label ID Required, if non-trivial documentation needs to be created by the ID team.
  • ID adds label ID Required - Trivial, if no design will be performed and only trivial ID updates are needed.
• Serviceability Requirements Identified. (Owner and Serviceability focal point)
• SVT Requirements Identified. (Owner and SVT focal point)
• Performance testing requirements identified. (Owner and Performance focal point)

Design

• POC Design / UFO review requested.
  • Owner adds label Design Review Request
• POC Design / UFO review scheduled. (David Chang)
• POC Design / UFO review completed.
• POC / UFO Review follow-ons completed.
• Design / UFO approved. (OpenLiberty/chief-architect) or N/A
  • (OpenLiberty/chief-architect) adds label Design Approved
  • Add the public link to the UFO in Box to the Documents section.
  • The UFO must always accurately reflect the final implementation of the feature. Any changes must be first approved. Afterwards, update the UFO by creating a copy of the original approved slide(s) at the end of the deck and prepend "OLD" to the title(s). A single updated copy of the slide(s) should take the original's place, and have its title(s) prepended with "UPDATED".

No Design

• No Design requested.
  • Owner adds label No Design Approval Request
• No Design / No UFO approved. (OpenLiberty/chief-architect) or N/A
  • Approver adds label No Design Approved

FAT Documentation

• "Feature Test Summary" child task created
  • Use the Feature Test Summary Template
  • Add FTS issue link to the Documents section.

---

Implementation

A feature must be prioritized and socialized (or No Design Approved) before any implementation work may begin and is the minimum before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlines in GA section.

Feature Development Begins

• Add the In Progress label

Legal and Translation

In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.

Legal (Complete before Feature Complete Date)

• Changed or new open source libraries are cleared and approved, or N/A. (Legal Release Services/Cass Tucker/Release PM).
• Licenses and Certificates of Originality (COOs) are updated, or N/A

Translation (Complete 1 week before Feature Complete Date)

• PII updates are merged, or N/A. Note timing with translation shipments.

---

Beta

In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.

Beta Code

• Beta fence the functionality
  • kind=beta, ibm:beta, ProductInfo.getBetaEdition()
• Beta development complete and feature ready for inclusion in a beta release
  • Add label target:beta and the appropriate target:YY00X-beta (where YY00X is the targeted beta version).
• Feature delivered into beta
  • (OpenLiberty/release-manager) adds label release:YY00X-beta (where YY00X is the first beta version that included the functionality).

Beta Blog (Complete 1.5 weeks before beta eGA)

• Beta blog issue created and populated using the Open Liberty BETA blog post template.
  • Add a link to the beta blog issue in the Documents section.

---

GA

A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.

Feature Complete

• Feature implementation and tests completed.
  • All PRs are merged.
  • All epic and child issues are closed.
  • All stop ship issues are completed.
• Legal: all necessary approvals granted.
• Translation: All messages translated or sent for translation for upcoming release
• GA development complete and feature ready for inclusion in a GA release
  • Add label target:ga and the appropriate target:YY00X (where YY00X is the targeted GA version).
  • Inclusion in a release requires the completion of all Focal Point Approvals.

Focal Point Approvals (Complete by Feature Complete Date)

These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.

All Features

• APIs/Externals - Externals have been reviewed or N/A. (OpenLiberty/externals-approvers)
  • Approver adds label focalApproved:externals
• Demo - Demo is scheduled for an upcoming EOI or N/A. (OpenLiberty/demo-approvers)
  • Add comment @OpenLiberty/demo-approvers Demo scheduled for EOI [Iteration Number] to this issue.
  • Approver adds label focalApproved:demo.
• FAT - All Tests complete and running successfully in SOE or N/A. (OpenLiberty/fat-approvers)
  • Approver adds label focalApproved:fat.

Design Approved Features

• ID - Documentation is complete or N/A. (OpenLiberty/id-approvers)
  • Approver adds label focalApproved:id.

  • NOTE: If only trivial documentation changes are required, you may reach out to the ID Feature Focal to request a ID Required - Trivial label. Unlike features with regular ID requirement, those with ID Required - Trivial label do not have a hard requirement for a Design/UFO.

• InstantOn - InstantOn capable or N/A. (OpenLiberty/instantOn-approvers)
  • Approver adds label focalApproved:instantOn.
• Performance - Performance testing is complete or N/A. (OpenLiberty/performance-approvers)
  • Approver adds label focalApproved:performance.
• Serviceability - Serviceability has been addressed or N/A. (OpenLiberty/serviceability-approvers)
  • Approver adds label focalApproved:sve.
• STE - Skills Transfer Education chart deck is complete or N/A. (OpenLiberty/ste-approvers)
  • Approver adds label focalApproved:ste.
• SVT - System Verification Test is complete or N/A. (OpenLiberty/svt-approvers)
  • Approver adds label focalApproved:svt.

Remove Beta Fencing (Complete by Feature Complete Date)

• Beta guards are removed, or N/A
  • Only after all necessary Focal Point Approvals have been granted.

GA Blog (Complete by Feature Complete Date)

• GA Blog issue created and populated using the Open Liberty GA release blog post template.
  • Add a link to the GA Blog issue in the Documents section.

Post GA

• Replace target:YY00X label with the appropriate release:YY00X. (OpenLiberty/release-manager)

---

Other Deliverables

• OL Guides OL Guides assessment is complete or N/A. (Yee-Kang Chang)
• Standalone Feature Blog Post A blog post specifically about your feature or N/A. (OpenLiberty/release-architect)
  • This should be strongly considered for larger or more prominent features.
  • Follow instructions in the blogs repo.
• WDT Liberty Developer Tools work is complete or N/A. (Leonard Theivendra)

---

[utle]

@teddyjtorres please take a look.

[teddyjtorres]

Please see https://www.ibm.com/docs/en/was-liberty/nd?topic=liberty-invoking-session-management-endpoint-openid-connect to configure an RP to logout a user logged out of the OP. This uses OpenID Connect Session Management.

[jrvasta]

@teddyjtorres Your suggestion doesn't work in this case. OIDC session management only works when a web page from the RP is reloaded, which will load a fresh copy of the session management iframe from the OP, which will then have the updated session state after a logout. In this case the scenario is to go directly to the SAML IdP in a separate browser tab and log out of the SAML IdP. No RP web resource is reloaded, so none of the browser tabs holding RP resources "notice" that the session state has changed, since no new state was loaded from the OP.

[jrvasta]

Note also that OIDC session management suffers from the limitation that only RPs that a browser currently has pages loaded from get notified of the logout. If the user has visited other RPs but no longer has any tabs open from them, those RPs never get notified of the logout, because the mechanism is all client-based. That is why #11479 was implemented for us.

[teddyjtorres]

Thank you for the clarifications. The problem description stated a page reload,

Reload the https://liberty_RP/snoop page and the session is still active

Therefore the RP iframe would be able to check the login status. Also, the setInterval method as shown in the sample iframe would cause the check to be performed at the specified interval, until the window is closed.

If you cannot reload the page contrary to what was reported, then a different mechanism is needed. We will review #11479 within the context of the issue brought up here.

[teddyjtorres]

Reopening issue since there are newer details impacting the determination of this issue.

[jrvasta]

@teddyjtorres I'm sorry; you're right - I missed the manual reload of the RP page in this scenario. Unfortunately, this simple scenario does not reflect what we're looking into, which is using our ELM applications instead of "snoop", and those applications do implement OIDC session management. Therefore, the real issue is that OIDC session management does not seem to detect any change in session state after doing a logout at the SAML IdP.

[teddyjtorres]

Thank you for the clarification. Please indicate if your RP's iframe uses setInterval to setup the checks for login status on a specified interval without having to have the page reloaded.

If so, then the session state may not have been updated after the SAML logout and we will need to investigate further.

[jrvasta]

Yes, the RP iframe has a timer that causes it to check the session status every 3 seconds.

I just set up an installation of ELM with the Liberty OP in release 21.0.0.3. This is without SAML, just using a basic user registry. It appears session monitoring isn't working at all, because this code in the Liberty opiframe.js script is always triggering:

function receiveMessage(message) {
if (message.origin !== EXPECTED_ORIGIN) {
console.log("Unable to complete request from " + message.origin);
return;
}

EXPECTED_ORIGIN is defined in the response from /oidc/sessionMgmt.jsp (which was a redirect from /oidc/endpoint/jazzop/check_session_iframe):

var EXPECTED_ORIGIN = 'https:';
var BROWSER_STATE_COOKIE_NAME = 'oidc_bsc';

EXPECTED_ORIGIN is always just 'https:'. In the browser console is a steady stream of messages like

Unable to complete request from https://elmhost.example.com:9443

showing that message.origin does not match EXPECTED_ORIGIN (ever).

We didn't notice this because we implemented the support for #11479, so that is accomplishing the logout notifications anyway.

Therefore, the first problem is that it seems session management is completely broken anyway.

[teddyjtorres]

Thank you for confirming that your RP's iframe is set to check periodically. As for the EXPECTED_ORIGIN, this should have had a value of the referrer's URL, excluding the path, per https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.security.openidconnect.server/resources/sessionMgmt.jsp. We need to investigate why it was only 'https:' in your environment.

[jrvasta]

I've checked three environments now, and they all have the same value for EXPECTED_ORIGIN. This includes our self-host environment at https://jazz.net/jazz

[jrvasta]

I have now checked five different environments; in four of them, EXPECTED_ORIGIN always has the value "https:". But in one of them, it has the correct value. I have no idea why, but that should probably be a separate issue. In the one environment where OIDC session management is working, I have determined that it won't work for this scenario. The reason is that the Liberty OP iframe script validates session state by using the contents of the "oidc_bsc" cookie, and that cookie is returned in the response from the /authorize endpoint. Therefore, the only way an updated value will be sent to the browser is when the browser is directed through an auth flow causing it to send a request to /authorize; just reloading a web resource from an RP won't do that.

Therefore, the summary of this issue is "when directly logging out of a SAML IdP that a Liberty OP is configured to delegate authentication to, there seems to be no way that RPs can be notified of the logout". (Note that this is a simplified version of the setup that our customers are complaining about, where they have both our applications and some other applications configured to use the same SAML IdP, and after establishing sessions with both of them, logging out of the other application does not somehow "propagate" to our applications, even though both the SAML IdP and the Liberty OP seem to "know" about the logout.

[teddyjtorres]

Further analysis of the scenario and section 3.7.2 Element <LogoutResponse> of the SAML's core specification in https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf leads to the conclusion that it is not possible to use a front channel approach to notify the RP of the logout using its post_logout_redirect_uri endpoint. The reason is as follows.

Section 3.7.2 indicates that the SP must return a LogoutResponse for an IdP's LogoutRequest. As such, the response to the IdP with the LogoutResponse message will be committed. Therefore, there is no front channel mechanism through the user agent to indicate to the RP that the logout happened using a post logout endpoint and tell it which clients the user interacted with.

If on the other hand a back channel approach is devised, then as indicated in https://openid.net/specs/openid-connect-backchannel-1_0.html#Introduction, there would not be access to the cookies keeping track of the session, WasOAuthTrackClients in particular which was relevant for #11479. This approach is still being analyzed, where an update to the WasOAuthTrackClients cookie is done during the LogoutResponse to the IdP and then the RP is notified using a back channel in post logout processing.

[teddyjtorres]

Given the conclusion in my previous comment, we need to implement OpenID Connect Back-Channel Logout 1.0 to satisfy your requirement.

[jimmy1wu]

demoed in the 24.02 EOI (january 23, 2024)

[jimmy1wu]

@OpenLiberty/serviceability-approvers

UFO: Does the UFO identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?

Yes, the Serviceability slide covers the common error scenarios. Many new NLS messages have been written and verified in FAT testing.

Test and Demo: As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team). a) What problem paths were tested and demonstrated? b) Who did you demo to? c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3?

a) Problem paths tested/demonstrated:

• The Logout Token could not be decrypted
• The signature for the Logout Token could not be verified
• Any of the iss, aud, or iat claims could not be validated
• The Logout Token does not contain a sub or sid claim
• The Logout Token does not contain an event claim with the http://schemas.openid.net/event/backchannel-logout value
• The Logout Token contains a nonce claim when it must not contain one
• The Logout Token with a jti claim is reused
• The iss, sub, or sid claim in the Logout Token does not match the corresponding claim in the ID token
• List what RPs failed to logout in the OP side
• An RP did not respond in time
• An RP could not logout the user

b) Demonstrated to testing team (Chris Crane)

c) Yes, serviceability needs are believed to have been met

SVT: SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered. a) Who conducted SVT tests for this feature? b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?

There was no SVT needed for this feature.

Service: Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.

WAS L2: SEC
WAS L3: Security SSO

Metrics: Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs?

N/A

[jimmy1wu]

@OpenLiberty/ste-approvers STE slides uploaded to the STE archive.

[tngiang73]

@jimmy1wu : WASSEC L2 is good with the STE slides. Hence, STE approved.

[jimmy1wu]

@OpenLiberty/accessibility-approvers - There are no accessibility requirements for this feature. Please let me know approval can be granted or if anything else is needed.

[jimmy1wu]

@OpenLiberty/externals-approvers - Can you please review the APIs/Externals approval for this feature? Please let me know approval can be granted or if anything else is needed.

[jimmy1wu]

@OpenLiberty/performance-approvers - There are no performance requirements for this feature. Please let me know approval can be granted or if anything else is needed.

[jimmy1wu]

@OpenLiberty/svt-approvers - There are no SVT requirements for this feature. Please let me know approval can be granted or if anything else is needed.

[jimmy1wu]

@OpenLiberty/globalization-approvers - Most NLS messages have been translated. Some new NLS messages and metatype names/descriptions were added earlier this month and they all made it in before the English cutoff date for 24002, so they should be translated in-time for 24002. Please let me know if approval can be granted or if anything else is needed.

[jimmy1wu]

@OpenLiberty/id-approvers - No updates are needed for existing docs. I've created a BETA blog issue (#27362) and GA blog issue (#27477) with info about the feature and how to use it. We plan on creating a new standalone doc page for back-channel logout after GA. Please let me know if approval can be granted or if anything else is needed.

[chirp1]

Adam, Jimmy, David, and I slacked. At this time no doc updates that the ID team writes are required for the customer to be able to use the feature. So, I removed the ID required label. No approval is necessary because the epic has the "Design approved" label on it.

[tjwatson]

Discussed this with @ayoho. We believe the <localStore/> config for this is not something we will encourage to be used in a production environment with containers. This makes it a rather low priority item from an InstantOn perspective. It would be a nice to have test to make sure the config can be applied at restore. But given we do not think it likely to be used in a container deployment with IntantOn, I do not believe that is a blocking item for this feature to release. I'm giving the InstantOn approval based on that.