1680
|
|
|
Daniel Manrique |
5 years ago
|
|
|
1679
|
|
Actually honor SAML AuthnRequests' NameIDPolicy format.
This was done to accommodate SPs (Bomgar) which request persistent names, indicating so in their AuthnRequest. SSO usually ignores this and always sends "email"-policy names, which most SPs handle fine but Bomgar fails with.
The fully-correct thing to do would be to always honor the AuthnRequest and support most/all of the SAML-specified policies, but that'd be a large effort and risks changing semantics for other SPs, which would prevent people from logging in, which would be bad.
Another quirk is that, while we respond saying we're giving a persistent identifier, our identifier (the e-mail address) does NOT actually conform to persistent semantics per SAML spec's section 8.3; we are sending the same value (the e-mail address), just saying it's "persistent" as requested by the SP. We do have a persistent identifier (the OpenID) but we can't send that because then it gets sent as the username, identifier, and email address. Again, support for this can be added to our django-saml2-idp fork but it's more work for something that at the moment is required only by one SP.
Due do the above, in order to support Bomgar (and possibly other SPs) in a more selective way, we only honor a non-email NameIDPolicy if: - the SP is configured to honor this (a boolean in the SPConfig) - the requested NameID policy is "persistent".
This allows us to switch this on only for very specific SPs for which we have more control and fully understand the consequences of "lying" with our "persistent" support.
In all other cases, we continue ignoring/overriding this and always sending our response with "email" policy.
(As a rant, the best thing to do would be to trash our hacky SAML library and integrate OneLogin's SAML library which is fully standards-compliant, which is however a huge undertaking we would have to consider and prioritize)
Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/support-saml-persistent-nameid-policy-format/+merge/361982
|
Daniel Manrique |
5 years ago
|
|
|
1678
|
|
|
Daniel Manrique |
5 years ago
|
|
|
1677
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1676
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1675
|
|
|
Tom Wardill |
5 years ago
|
|
|
1674
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1673
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1672
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1671
|
|
|
Tom Wardill |
5 years ago
|
|
|
1670
|
|
|
Tom Wardill |
5 years ago
|
|
|
1669
|
|
|
Tom Wardill |
5 years ago
|
|
|
1668
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1667
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1666
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1665
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1664
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1663
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1662
|
|
|
Maximiliano Bertacch... |
5 years ago
|
|
|
1661
|
|
|
Daniel Manrique |
5 years ago
|
|
|