Feature Test Summary for OIDC Back-Channel Logout

Test Strategy

Test strategy & approach The backchannel logout changes include the addition of the configuration attribute backchannelLogoutUri. When backchannelLogoutUri has a value and one of several "logouts" is invoked, the uri specified will be invoked. The default value is https://<host>:<securePort>/oidcclient/backchannel_logout/<oidcProvider> when using an OIDC client and https://<host>:<securePort>/ibm/api/social-login/backchannel_logout/<oidcProvider> when using a Social client. The backchannelLogout endpoint will clean up client cookies.

The FATs for this feature are testing using different logout mechanism and verifying that the correct tokens/cookies/sessions are getting cleaned up or modified (and that tokens/cookies/sessions that should not be cleaned up or modified are not)
The FATs for this feature are verifying that the id_token_hint that is created for the logout contains the correct attributes and values. We're verifying that tokens that are missing required attributes are detected, errors logged and the logout terminated. We're also verifying that tokens that contain mis-matched values (values that don't match the request/provider that the request targets) are detected, errors logged and the logout terminated.
The FATs for this feature are verifying that we can register and use clients from an external OAuth client registry (as well as use clients in a local client registry (not recommended for production))
The FATs for this feature are verifying the correct the proper behavior when the backchannel endpoint is invoked with all supported HTTP_METHODS (get/post/delete/...)
The FATs for this feature are verifying that the discovery endpoint is returning infor for backchannel logout.
The FATs for this feature are verifying that the registration endpoint allows backchannel logout config attributes to be configured.
The FATs for this feature are verifying that the clientMetadata endpoint is returning info for the backchannelLogoutUri.

List of FAT projects affected

com.ibm.ws.security.fat.common.backchannelLogout
com.ibm.ws.security.oidc.client_fat.backchannelLogout.1
com.ibm.ws.security.oidc.client_fat.backchannelLogout.2
com.ibm.ws.security.oidc.client_fat.backchannelLogout.saml.1
com.ibm.ws.security.oidc.client_fat.backchannelLogout.saml.2
com.ibm.ws.security.oidc.server_fat.backchannelLogout
com.ibm.ws.security.social_fat.LibertyOP.backchannelLogout.1
com.ibm.ws.security.social_fat.LibertyOP.backchannelLogout.2
com.ibm.ws.security.oidc.server_fat.endpoint.discovery (WS-CD)
com.ibm.ws.security.oidc.server_fat.clientregistration (WS-CD)

Test strategy

New function
Function has been added to send logout notifications back to RPs via Liberty OIDC Provider.
A new config attribute was added to specify a backchannel logout uri. With this configured, the OP will make a call of the client (OIDC or Social) to complete logout.
Testing Performed
[ ] HTTP Methods - Tests are run with both an OIDC client and with a Social client since these tests target the client side of the support
Supported methods - invoke and show that 200 status codes are returned
- OPTIONS
- POST
Invalid methods - invoke and show that the expected status code is returned
- GET - 403
- PUT - 403
- HEAD - 403
- DELETE - 403
- PATCH - 501
- TRACE - 403
[ ] Validate Logout Token - Tests are run with both an OIDC client and with a Social client since these tests target the client side of the support
Invoke the back channel logout endpoint with a valid logout token (id_token_hint) - verify that the token is accepted as valid
Invoke the back channel logout endpoint without a logout token (id_token_hint) - verify that we get a 400 status code along with the appropriate error messages logged by the server
Invoke the back channel logout endpoint with a random string instead of a logout token - verify that we get a 400 status code along with the appropriate error messages logged by the server
Invoke the back channel logout endpoint with a logout token that has omitted a required claim - verify that we get a 400 status code along with the appropriate error messages logged by the server
Invoke the back channel logout endpoint with a logout token that has extra claims - verify that the token is verified and a 200 status code is returned
Invoke the back channel logout endpoint with a logout token that has an invalid value specified for one of the claims (issuer doesn't match client, iat or exp is not valid (iat in future, exp expired, iat after exp), events claim doesn't contain "http://schemas.openid.net/event/backchannel-logout", ...) - verify that we get a 400 status code along with the appropriate error messages logged by the server
Invoke the back channel logout endpoint with various combinations of the "sid" and "sub" claims
[ ] Core Back channel logout tests
There are multiple ways that logout can be initiated and these core/basic tests are performed using each of the following (the same tests are run multiple time altering the configuration for each of the following repeats):
- (OPServer)/.../logout
- (OPServer)/.../end_session
- (OPServer)/.../ibm_security_logout
- (OPServer)/.../testApp invoking req.logout()
- (RPServer)/.../testApp invoking req.logout() and then calling /.../logout
- (RPServer)/.../testApp invoking req.logout() and then calling /.../end_session
- (IDPServer)/idp/profile/Logout (authentication via SAML tests - IDP Initiated logout)
- (OPServer/SPServer)/ibm/saml20/defaultSP/logout (authentication via SAML tests - SP Initiated logout)
The tests set up servers to run in the following setups:
- OIDC OP Server (local OAuth client config) and an OIDC RP
- OIDC OP Server (Mongo OAuth client DB) and an OIDC RP
- Shibboleth IDP, and OIDC OP using SAML SP for authentication and an OIDC RP
- OIDC OP Server and a Social Client
For each test run, the following will be validated (the tests will make sure that tokens, cookies, sessions either exist or do not exist as appropriate
- Try to use the original webClient (browser instance) to access the protected app again
- Try to use the access_token to access the protected app again
- Try to use the refresh_token to create a new access_token
- Does the OP cookie exist and is it usable
- Does the Client cookie exist and is it usable
- Does the SP cookie exist and is it usable (only for instances using SAML)
- Does the IDP cookie exist and is it usable (only for instances using SAML)
Basic/Core tests run:
- Basic end to end test with a confidential client (variations with https required true/false configured)
- Basic end to end test with public client (variations with and without a client secret configured, variations with https required true/false configured)
- Basic end to end test with a confidential client with idTokenCacheEnabled = true/false
- Basic end to end test with a confidential client with accessTokenCacheEnabled = true/false
- Login multiple times using the same provider/client/user, then logout (with/without the id_token_hint)
- Login multiple times using the same provider/client and different users, then logout (with/without the id_token_hint)
- Login multiple times using the same provider/user and different client, then logout (with/without the id_token_hint)
- Login multiple times using different provider/client and the same user, then logout (with/without the id_token_hint)
- Login using one provider/client/user and logout specifying a different provider through the logout (logout token doesn't match the provider used to logout) (with/without the id_token_hint)
- Login multiple times - different combinations of providers/clients/users and use a test app in place of the default backchannelLogout uri - the test app logs the details of what is getting logged out - tests validate that the correct backchannelLogout was called.
- Tests use a test backchannelLogout app that returns non-200 status codes - make sure that the overall logout returns a 200 status code
- Test uses an invalid backchannelLogoutUri make sure that the normal logout is done and the bad uri does not result in a non-200 status code.
- Test starts with a config that has an invalid backchannelLogoutUri. Reconfigure the server to replace that uri with the valid default value - make sure that we successfully complete the logout.
- Test uses a config that does not specify the backchannelLogoutUri and confirms that only the standard logout is performed - the backchannel logout steps are not done.
- Test with app-passwords enabled. Create app-passwords and then logout. Make sure that we can still use the app-passwords to create app-tokens to login after the logout.
- Test with app-tokens enabled. Create app-tokens and then logout. Make sure that we can still use the app-tokens to login after the logout.
- Try to use a logout token to access a protected app.
- Set a low userClientTokenLimit and login the maximum number of times, logout and then show that we can log in again.
- End to end test with accessTokenInLtpaCookie=true (default is false)
- End to end test with accessTokenCacheEnabled=false (default is true)
[ ] MultiServer test
- Test with multiple client servers - multiple RP's or Social Clients and an RS Server.
- Login using multiple (Oidc/OAuth) clients and different users from different client servers to access protected apps.
- Oidc config has a test app configured as the backchannelLogoutUri's - when called, they log information about the target of the backchannelogout request.
- Tests logout and verify that all of the correct backchannel requests is made
- Test variations for using the same or different webClients to do the logout are run
- Test variations for passing or not passing the id_token_hint on the logout are run
[ ] Discovery endpoint
Update the discovery tests to ensure that the backchannel_logout_supported and backchannel_logout_session_supported are returned when the discovery endpoint is invoked.
[ ] Client Registration endpoint
Update the registration endpoint tests to ensure that we can configure the back channel configuration attributes in a client registry entry.
[ ] Clent Metadata endpoint
Update the clientMetadata endpoint tests to ensure that the backchannelLogoutUri information is returned
[ ] Revoke endpoint
Added tests to use the revoke endpoint and verify that the back channel logout is NOT done.
[ ] No manual tests exist or are needed

Confidence Level

4 - We believe that all of the necessary positive and negative tests have been written and delivered. Would mark this as a 5, but there are so many combinations/variations.

OpenLiberty / open-liberty