« back to all changes in this revision
Viewing changes to src/ubuntu_sso_saml/tests/test_processors.py
- Committer: Ubuntu One Auto Copilot
- Date: 2019-01-24 14:44:23 UTC
- mfrom: (1677.2.2 support-saml-persistent-nameid-policy-format)
- Revision ID: otto-copilot@canonical.com-20190124144423-1jz0j4k2cw71t0pb
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
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
added
removed
src/ubuntu_sso_saml/tests/test_processors.py
