Merge lp:~roadmr/canonical-identity-provider/support-saml-persistent-nameid-policy-format into lp:canonical-identity-provider/release
Status: | Merged |
---|---|
Approved by: | Daniel Manrique |
Approved revision: | no longer in the source branch. |
Merge reported by: | Otto Co-Pilot |
Merged at revision: | not available |
Proposed branch: | lp:~roadmr/canonical-identity-provider/support-saml-persistent-nameid-policy-format |
Merge into: | lp:canonical-identity-provider/release |
Prerequisite: | lp:~roadmr/canonical-identity-provider/honor-authnrequest-nameid-policy-format-field |
Diff against target: |
140 lines (+88/-5) 2 files modified
src/ubuntu_sso_saml/processors.py (+15/-0) src/ubuntu_sso_saml/tests/test_processors.py (+73/-5) |
To merge this branch: | bzr merge lp:~roadmr/canonical-identity-provider/support-saml-persistent-nameid-policy-format |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Maximiliano Bertacchini | Approve | ||
Review via email: mp+361982@code.launchpad.net |
Commit message
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-
which is however a huge undertaking we would have to consider and prioritize)
Description of the change
This change was requested by the support folks (Mark Thomas) to allow them to use SAML authentication on their Bomgar box (for providing remote screensharing for support purposes), avoiding the need to add users manually.
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-
which is however a huge undertaking we would have to consider and prioritize)
I'm not too familiar with this, but looks good to me.