Requested/Supported Principals

[Marvin Addison]

I'm really struggling to meet all requirements for our assurance
implementation with a single X509 flow. The root problem is that we have
two different certificate types handled by the one flow, but the assurance
characteristics differ between the two types. Thus we need to be able to
signal silver or bronze as a function of subject/credential instead of the
flow/component. I can imagine this would be a common requirement for
assurance use cases where the assurance levels are driven by data of the
authenticated subject. For example, some institutions store the assurance
level as a directory attribute.

It feels like there should be some first-class consideration for driving
the requested/supported principal machinery from the subject. Based on
initial analysis I can imagine a well-defined post-authentication hook to
set arbitrary principals (e.g. AuthnContextClassRefPrincipal) on the
authenticated subject, which would be checked in a subsequent flow action
as candidates for setting RequestedPrincipalContext#setMatchingPrincipal().
It's not clear how to combine subject-based and component-based supported
principals, but I'm hopeful there's a reasonable solution. My assumption is
that subject-based evaluation would be an optional feature in addition to
the component-based machinery that's enabled by default.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150513/cefc15b9/attachment.html>