Authentication Subsystem

[Cantor, Scott]

On 8/16/13 11:12 AM, "Marvin S. Addison" <marvin.addison at gmail.com> wrote:

>AuthenticationContext has slots for both passive and forced
>authentication, but I don't see where those are set. I imagine that the
>profile handling subsystem is generally the place where the details of
>passive/active are implemented, but the AuthenticationContext isn't
>available yet.

I wouldn't say implemented, but "known", yes.

>It seems it would be more straightforward to set the passive/forced flags
>on AuthenticationContext at the profile handling layer in a
>profile/protocol dependent fashion. In that case the profile handling
>layer is responsible for initialization of AuthenticationContext, which
>at face value seems awkward. Am I thinking about this clearly?
>Alternative/better approaches?

I think it's necessary to have the profile layer do it, yes. That's not
awkward, IMHO, because the context is the input, or parameters if you
will, to the subflow that makes up authentication. It's the "caller" that
supplies the input, so it's the profile handling flow that needs to create
the context and populate it in part.

The other subsystems, AFAIK, work the same way. It's the caller of the
resolver that creates the AttributeResolutionContext, I would assume. It's
definitely that way with the SubjectCanonicalization step I created. If
you look at the code, it's a stage of the authentication flow that creates
that context before control would transfer to the c14n flow.

-- Scott