authentication context class default is unexpected
Basics
Logistics
Basics
Logistics
Description
In SAML 2, in the absence of a specific context class being requested by the SP, the V3.0.0 IdP uses urn:oasis:names:tc:SAML:2.0:ac:classes:Password.
After discussion with Scott, this does not appear to be a default in the sense of a predictable and documented value. Instead, it's an arbitrary element extracted from a Set of compatible values. This means that at least in principle that a different value (in particular, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport) might be used if the implementation details of that Set changed. This potential seems undesirable.
It is possible to set the default context class per-profile to achieve particular results, which would override this implicit not-quite-default. So people who care about this and aren't happy with the current behaviour have a way to get what they want.
However, I think that:
It would be better for us to have a stable and documented default than to have one which is not under our control and might change without warning
It would be nice for that default to be available as an IdP property associated with SAML2 in general, so that it can be changed for all profiles in a single place
It would make sense for the default default (for password authentication flows) to be urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport as that's what every IdP should be using
Environment
None
Activity
Scott Cantor
February 20, 2015 at 3:23 AM
r7356
Optional bean shibboleth.AuthenticationPrincipalWeightMap added to general-authn.xml
I could have hidden this, but that seemed questionable. The downside is that 3.0 installs won't have the bean defined and won't prioritize PPT, but that doesn't seem like a huge problem this early.
Scott Cantor
February 18, 2015 at 2:06 AM
Easiest way to implement seems like injecting a map of Principals to Integers for weighting, and then do Subject->Set->Array->Arrays.sort with a Comparator that uses weights from the map.
Scott Cantor
February 11, 2015 at 6:30 PM
After discussion, it seemed that the best way to tweak this without adding a lot of overhead for deployers is to adjust the internal function that populates authentication statements with the "right" custom principal from the Java Subject to use a weighted algorithm that favors certain methods over others when there's no explicit choice to use.
In SAML 2, in the absence of a specific context class being requested by the SP, the V3.0.0 IdP uses
urn:oasis:names:tc:SAML:2.0:ac:classes:Password.After discussion with Scott, this does not appear to be a default in the sense of a predictable and documented value. Instead, it's an arbitrary element extracted from a
Setof compatible values. This means that at least in principle that a different value (in particular,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport) might be used if the implementation details of thatSetchanged. This potential seems undesirable.It is possible to set the default context class per-profile to achieve particular results, which would override this implicit not-quite-default. So people who care about this and aren't happy with the current behaviour have a way to get what they want.
However, I think that:
It would be better for us to have a stable and documented default than to have one which is not under our control and might change without warning
It would be nice for that default to be available as an IdP property associated with SAML2 in general, so that it can be changed for all profiles in a single place
It would make sense for the default default (for password authentication flows) to be
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportas that's what every IdP should be using