Subject Canonicalization

Rod Widdowson rdw at steadingsoftware.com
Mon Jan 13 08:50:25 EST 2014


I spent some time looking at this this weekend and, having chatted briefly
to Scott, I think I have a proposal.  I’d welcome factual corrections and
suggestions for changes to the below.

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

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 configuration around selection of which c14n action is to be called
during authentication is already defined.  Each authentication flow has an
associated flow descriptor [3] and into this the flow Id of the c14n stage
can be injected.

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.

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.

The actual implementation of the conversions (as defined by each
PrincipalConnector will probably be done in the idp-saml-impl classe).

Other C14 actions.

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.

I would propose that we also consider supplying two further connectors, to
allow arbitrary complicated c14n.

1) A SciptedCanonicalizationAction, to allow ECMA scripting.  The variables
made available to the script would contain either the Subject, and/or the
SubjectC14NContext and/or a list of {id,value} pairs where each id is the
class of the Principal and the values are the result of calling #getName()
on it/them (a subject can contain multiple Principals of the same class).

2) A ResolutionBasedCanonicalizationAction.  The idea here, floated at or
just after the Columbus meeting is to define a separate AttributeResolver.
The resolver can be defined via (a super set of) the attribute resolver
schma and constrained to output one attribute of a pre-defined name with
exactly one StringValue.  The superset part of the definition would be a
<DataConnector> which injected the contents of the Subject as a series of
names attributes (as per the SciptedCanonicalizationAction mentioned above).

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.

/Rod

[1]
https://build.shibboleth.net/jenkins/job/java-identity-provider-nightly/java
doc/net/shibboleth/idp/authn/context/SubjectCanonicalizationContext.html
[2]
https://build.shibboleth.net/jenkins/job/java-identity-provider-nightly/java
doc/net/shibboleth/idp/authn/impl/SimpleSubjectCanonicalization.html
[3]
https://build.shibboleth.net/jenkins/job/java-identity-provider-nightly/java
doc/net/shibboleth/idp/authn/AuthenticationFlowDescriptor.html



More information about the dev mailing list