Subject Canonicalization

[Cantor, Scott]

On 1/13/14, 8:50 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>The basic aim is to have multiple Actions which work on the
>Canonicalization
>(c14n) Context[1] to produce the single principal.  We already have a
>simple
>one of these implemented as net.shibboleth. SimpleSubjectCanonicalization
>[2] (which works on the UsernamePrincipal).

Small correction: the process produces a String name, not a Principal.

>I¹ll note that there are at least two places where these actions may be
>called. One is the one we have deployed right now being the SSO flows; in
>this case the role is to extra the principal from the result of
>Authentication (via the Subject).  Another place is in the attribute query
>and related flows, where the SP is providing a NameID or NameIdentifier.
>In
>this case the idea is to wrap this information into distinguished
>Principals
>(NameIDPrincipal/NameIdentifierPrincipal) place that into the c14N context
>and call the c14n action.  There may well be other cases where principal
>c14n is needed.

The NameID case comes up in SAML 2 when the request contains a Subject
element. We have to reverse that into a name, and then validate that the
result of the authentication matches that name, or fail the request. Easy
to do once we have this implemented for queries.

>The configuration around selection of which c14n action is to be called
>for
>normalization of NameIDs to be called is tbd.  Initially we may well
>decide
>to hard wire it, longer term there are other strategies available to us,
>starting with specifying the class as a property, to the full complexities
>used for authentication.

I favor doing something more or less the same as authentication so it's
consistent.

>The configuration of what the NameID c14n stage *does* is defined in the
>attribute resolver file via the <resolver:PrincipalConnector> stanzas.
>Hence the AttributeResolver Interface needs to gain a method which goes
>from
>a SubjectC14NContext (if the MVN dependencies allow) to a String, being
>the
>principal.   Then the Attribute request c14n action consists of doing the
>usual Reloadable Spring Service Dance to get the Attribute resolver, and
>calling the resolver¹s c14n method.

What I was thinking is maybe we could build a c14n flow that internally
decides what to do based on the same config file as the resolver, for
compatibility, but isn't really part of the resolver. And we would
deprecate that approach, and provide a more direct config path.

>In addition to the existing  SimpleSubjectCanonicalization  and the
>proposed
>PrincipalConnectorCanonicalization, we will need several other C14N
>implementations.  For instance we will probably need one for
>KerberosPrincipal which can be taught to strip (or otherwise) the
>@DOMAIN.MUMBLE.EDU stuff.

So far that hasn't been needed because our core code always generates a
UsernamePrincipal and that can be run through various transforms, but we
can take a look at things.

>I thing that the SciptedCanonicalizationAction is worth investigating.
>The
>ResolutionBasedCanonicalizationAction represents a huge amount of bang
>(LdapLookup, RDBMS lookup, Scripting and so forth) for not much buck.
>But I
>am not totally convinced that we should spend the to do this in V1.

I think it would be best to just verify that if one wanted to do the work,
one could create a flow that invokes the resolver, but I don't think we
need necessarily make it a special resolver.

-- Scott