Requested/Supported Principals

[Cantor, Scott]

On 5/13/15, 1:47 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:



>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.

I intended for that to work, but I made a mistake handling the subject 
coming back and tried to automate a different set of cases and that broke 
the ability to limit the Principal collection programatically. Basically I 
wanted to avoid the need for writing code in the majority of cases, and in 
the process made it impossible with those flows to actually rely on 
writing code.

There's nothing architecturally limited about it, the problem is in the 
AbstractValidationAction base class and the way Subjects coming back are 
manipulated by it and by the subclasses. The subclasses are just 
implementation so I can change them, but the base class is causing 
problems too, and it's API, so I have to come up with an addition to the 
API to help fix it.

>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().

Breaking it apart is an option, but I don't know that it's feasible 
without breaking APIs at this point, so I'm looking for a less invasive 
change, probably some kind of flag to control whether to add to the 
Principal collection. That already is there, but it wasn't expressed 
correctly and I have to back out what I did and come up with a set of 
options that allow it to work better.

-- Scott