| 1693
|
|
|
Matias Bordese |
4 years ago
|
 |
|
| 1692
|
|
|
Daniel Manrique |
4 years ago
|
|
|
| 1691
|
|
|
Guillermo Gonzalez |
5 years ago
|
|
|
| 1690
|
|
|
Guillermo Gonzalez |
5 years ago
|
|
|
| 1689
|
|
|
Daniel Manrique |
5 years ago
|
|
|
| 1688
|
|
|
Celso Providelo |
5 years ago
|
|
|
| 1687
|
|
|
Po-Hsu Lin |
5 years ago
|
|
|
| 1686
|
|
|
Celso Providelo |
5 years ago
|
|
|
| 1685
|
|
SAML: Ensure all dicts used to build assertions contain only utf-8-encoded data.
The SAML library we use assumes use only of ascii inputs and parameters and Python 2 str <-> unicode implicit conversion intricacies. Some of those assumptions are broken by SSO's use of the library and particularly the CanonicalProcessor, which gets a lot of those assertion parameters and attributes from the database; SP config parameters, custom attributes come from Django ORM and are thus unicode, and since the SAML library doesn't do explicit unicode data encoding, it barfs when implicit conversions for unicode data that contains non-ascii characters are attempted, particularly when using the python string.Template classes and base64-encoding the final assertion;these behave predictably badly when given a str template and fed unicode substitution values.
Since the output is expected to be utf8-encoded XML, this MP just ensures all the pieces used by the library to assemble, sign and encode the assertion are sent as utf8-encoded strs rather than unicodes.
This problem was only exposed when we added a new "full name" substitution for SAML attributes: up until now, by some fluke, all the date we fed to the SAML library was ascii-only and so even when we were sending mixed strs and unicodes back and forth, implicit conversion of unicode to str worked fine and the problem went undetected. However, fullnames, unlike URLs and other identifiers, usernames and OpenIDs, understandably can contain non-ascii characters.
Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/saml-unicode/+merge/365615
|
Daniel Manrique |
5 years ago
|
|
|
| 1684
|
|
|
Celso Providelo |
5 years ago
|
|
|
| 1683
|
|
|
Celso Providelo |
5 years ago
|
|
|
| 1682
|
|
|
Daniel Manrique |
5 years ago
|
|
|
| 1681
|
|
|
Daniel Manrique |
5 years ago
|
|
|
| 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
|
|
|
collapse all