SAML SLO support

[andreas-kupries]

Issue:

Fix #38494

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

Problem

SURE 3572

Solution

PR holds work checkpoints at the moment. Not in a merge-able state.

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]

[macedogm]

What is our long term plan regarding this fork, please? Was this validated with the Architecture team? Just asking to understand our goals and if we plan to eventually go back to the original upstream version or not.

I see in our fork that we added some fixes and open (not merged) upstream PRs. Are we working with upstream to get those merged?

My concern is that this is a very sensitive library in terms of security, and it already had 5 CVEs - https://github.com/crewjam/saml/security . By going with the fork we might lose track of future CVE fixes.

[andreas-kupries]

Are we working with upstream to get those merged?

The PRs for the fixes we use look to have been ignored for more than a year, both.
And the project has lots of other open PRs which are not attended to.
It feels as if the entire project has fallen out of maintenance.
As such I am unsure how we could work with upstream to get these merged.

What is our long term plan regarding this fork, please?

Personally I would push for us to search for a better maintained replacement.

Was this validated with the Architecture team?

Who should I talk to ?

[macedogm]

@mattfarina WDYT about the situation described by Andreas, please?

[mattfarina]

@andreas-kupries I have a couple questions:

1. Do we have a documented list of changes we are carrying and the reason for each of them? I ask because 1) I am looking to understand the situation and 2) I've run into problems with other forks where we had lost that information and no longer knew.
2. Do we know of any alternative saml packages that are well maintained and stable? I suspect the answer is "no" because we have not looked but I wanted to ask. Just in case.

[andreas-kupries]

There is currently no documented list of changes, except through the commit messages in the fork.
I am ok with writing such a list. Where should it go ? (Just) in the forked repo, or elsewhere too ?

I know of https://pkg.go.dev/github.com/russellhaering/gosaml2 because during the search for the OKTA/KC issues it was used in part. The parts were removed again when the first crewjam patch was added, fixing the mishandling of compressed data. I did not research deeper into suitability at that point because SLO was scheduled for 2.9 at the time and I wanted it working, not go down another rabbit hole of changing the supporting package.

Some other packages I saw were explicitly marked as experimental, incomplete, etc.

[macedogm]

So just for my own understanding, https://pkg.go.dev/github.com/russellhaering/gosaml2 doesn't contain all the code and fixes that we need without having the need to still fork it too, right?

Note that our fork https://github.com/rancher/saml doesn't have main as the default branch, instead if points to v0.0.1-rancher1 which can be confusing. Would be good to update the default branch if possible, please.

[andreas-kupries]

https://pkg.go.dev/github.com/russellhaering/gosaml2

This package came up during work here as a possible alternative to crewjam/saml, which I did not investigate deeply enough to know if it provides everything we need, or not. I saw a fork of crewjam/saml as the less risky path than having to replace it with something completely new.

Would be good to update the default branch if possible, please.

Checking, I find that I do not have the admin permissions necessary to change the default path. Who should I talk to get the change done ?

[macedogm]

Thanks for the explanation, Andreas.

I saw a fork of crewjam/saml as the less risky path than having to replace it with something completely new.

Putting this into perspective, it does make sense.

The security implications, ownership and maintainability of such forks, that and others, will eventually be addressed in the Engineering Handbook (CC @mattfarina).

Checking, I find that I do not have the admin permissions necessary to change the default path. Who should I talk to get the change done ?

You must open a GH issue for EIO.

[andreas-kupries]

Ok.

[andreas-kupries]

Done: https://github.com/rancherlabs/eio/issues/2429