SAML SLO support

[andreas-kupries]

Issue:

See #38494

This work is co-dependent on the UI work tracked at rancher/dashboard#10941

Problem

SURE 3572

Solution

1. Extended AuthConfig, SamlConfig with the proposed flags about SLO (supported, enabled, forced).
   1. Based on the CRD setup the supported flag might be nonsense.
   2. As in, cannot be set into the initial AuthConfig CR instances. UI may have to simply know that only the SAML providers support SLO, and none of the others.
2. New structures SamlConfigLogoutInput, and ...Output. Same fields as the known SamlConfigTest... structures. Hold the request/response data from/to the UI for the logoutAll action (see below).
3. The tokens API should export a new action logoutAll.
4. Basic implemention of the logout flow. Compiles, untested.
5. Linkage between token manager and saml to invoke the flow from the frontend

KNOWN ISSUES: Does not guard against call of regular logout when SLO is forced.
Does guard against forced but not enabled, and call to logout-all when not enabled.

Testing

Engineering Testing

Manual Testing

Automated Testing

• Test types added/modified:
  • Unit
  • Integration (Go Framework)
  • Integration (v2prov Framework)
  • Validation (Go Framework)
  • Other - Explain: EXPLAIN
  • None
  • REMOVE NOT APPLICABLE BULLET POINTS ABOVE
• If "None" - Reason: EXPLAIN THE REASON
• If "None" - GH Issue/PR: LINK TO GH ISSUE/PR TO ADD TESTS

Summary: TODO

QA Testing Considerations

Regressions Considerations

TODO

Existing / newly added automated tests that provide evidence there are no regressions:

• TODO

[andreas-kupries]

Status report after a few days of working on implementing the thing:

The main visualization of the necessary workflow is taken from
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02_html_m50a2ba3e.gif
The same is described at https://xacmlinfo.org/2013/06/28/how-saml2-single-logout-works/

The main take I get from both is that the SP who initiated the SLO is not notified by the IdP that the user was logged out.

Okta seems to follow that principle, based on what I experienced with it today. I.e. I see a plain POST to Rancher's .../saml/slo endpoint, and based on the fact that I can see it in the browser's debug console I believe that this was indeed done by redirection from the initial norman action (logoutAll). Unfortunately this redirect looks to have lost tall he Cookies used by the SAML code to store the flow state. I am unsure if that may be because the response contained in the redirect is fail, not a success. Although I cannot see how the browser would know that. Only thing I can think of is that Okta unsets these, maybe all, cookies. The failure is not due to a bogus user reference. Looking at the Okta Events the logout request is recorded as such, and its recognizes the user. It claims to have found an Invalid signature.

That is weird because the signature on the logout request should be generated through the same code as for SSO, and use the same cert/key, and SSO is, well, successful. Given my should there is doubt on that, mainly because different key and such is the only way I can see this failure to happen. The code is still the same, service provider name is same, so same SP structures, same key data.

Also, Keycloak looks to be ok with the signature of the request, its issue looks to be somewhere else.

So, going back to KC, which I struggled with before trialing Okta today it seems that this IdP wants to notify the initiating SP also, possibly directly from itself. The initial failures I saw with it said Unable to finish logout because XXX endpoint is not set. With an endpoint set for it the other issues I seem to have with KC look to me as me not properly processing/responding to that notification.

It should be noted that the XXX endpoint is generally needed, namely to handle IdP initiated logouts, i.e. when Rancher and other apps share the IdP and users, and a user in the other apps performs a SLO.

Thus, if I can implement this endpoint properly then it should be possible to use KC completely.

---

In terms of the flow image at the beginning, for KC I am stuck in implementing the steps 3/4,
whereas for Okta I reach step 5 (with 3/4 skipped), it is just a failure response, not the expected success.

---

This is the state of the work as of commit 582687e.

Thanks to @aalves08 for providing access to a remote Okta IdP to work with.

[richard-cox]

@andreas-kupries At some point next week could you provide an linux/amd64 image of the changes in this PR? I'll be taking over from Alex whilst he's away and noticed he was using arm64

[andreas-kupries]

Managed a full logout with KC now.

That said, after that the UI does a number of things I was unable to track, and then landed on

https://tagetarl:8005/auth/login?err=An%20error%20occurred%20logging%20in.%20Please%20try%20again.

in the end. In other words, there may still be something more to do UI side.

Side note: I have to keep the haering SAML package. The logout response is deflate-compressed. haering handles that ok. crewjam does not try to decompress, tries to read the compressed string as XML and then fails with a bad utf-8 error.

[andreas-kupries]

Status report: SLO works for Keycloak and OKTA now.

• The keyword is detached signature
  • Not handled by crewjam/saml on receiving responses ➡️ KC issue
  • Not generated by crewjam/saml for logout redirect requests ➡️ OKTA issue
• Fixed now
  • 99%: Implement query signature verification crewjam/saml#449
  • 1% remainder: Implement query signature verification crewjam/saml#449 (comment)
• Commits to rancher/saml:
  • rancher/saml@e1e76fd
  • rancher/saml@a10be19

[crobby]

General comment. There seems to be quite a number of debug logs. Our debug logs overall in Rancher are super dense.
The answer may be, "yes", and that is fine, but have you considered removing any of these that might produce lots of output that isn't very high-value?

[andreas-kupries]

General comment. There seems to be quite a number of debug logs.

I tend towards higher amount of logging by default.

Our debug logs overall in Rancher are super dense. The answer may be, "yes",
and that is fine, but have you considered removing any of these that might
produce lots of output that isn't very high-value?

Weeded a bit, result is in commit [2a3bf9b]

[samjustus]

for posterity: security needs to finish pentesting before we can merge

[andreas-kupries]

The security review has completed as ok and closed.
I have the go ahead to merge.

This is deferred until 2.10 is open, i.e. 2.9 is released.

[andreas-kupries]

Relevant flaky test: #42248

[bigkevmcd]

I'm fine with this change, and I've been able to test it against Keycloak (with Backchannel logout URL).

But there is some tidying that could be done to make it easier for the next person to work on this?

[andreas-kupries]

Validation

Root Cause

A change request to support logging a User out of the session held by the configured external auth provider (EAP), and thus out of all applications, instead of just out of Rancher itself. This last meant that when logging back into Rancher the still-open session in the EAP allowed for quick login, without having to run through full authentication again. Confusing several users which expected to fully re-authenticate. Despite the notification on regular logout that the EAP session may be retained.

What was fixed, or what change have occurred

Several, not all, EAP now support an LogoutAll option and action.
The supporting EAP are the SAML variants on offer.

Note that the following changes are in the Dashboard, not in the Backend.

Supporting LogoutAll means that when such an EAP is configured and activated the Admin
can configure the checkboxes

• LogoutAllEnabled and
• LogoutAllForced.

Checking LogoutAllEnabled causes the UI to offer the user the choice between regular logout and logout all.
Additionally checking LogoutAllForced causes the UI to not offer regular logout anymore, only logout all.
And as the sole choice no actual choice is offered to the user. Logout is logout all.
Note that Forced cannot be checked if Enabled is not checked.

The backend sees these configuration flags as well and will react with errors should the dashboard try to

• invoke logout all when not enabled.
• invoke logout when logout all is forced.

Areas or cases that should be tested

• Dashboard
  • EAP configuration
    • Allow configuration of logout all for SAML providers.
    • Do not allow configuration of logout all for any other providers.
  • Logout
    • Use plain logout, with no choice, when logout all is not enabled (SAML) or not supported (any else).
    • Offer choice (dialog, IIRC) between logout and logout all when logout all is enabled.
    • Use logout all, with no choice, when logout all is enabled and forced.

What areas could experience regressions

• Dashboard logout.
• EAP configuration.

Are the repro steps accurate/minimal?