Subject Canonicalization problem

[Cantor, Scott]

On 11/7/15, 11:52 PM, "users on behalf of Doan, Tommy" <users-bounces at shibboleth.net on behalf of tdoan at smu.edu> wrote:



> 
>With this configuration, the IdP starts up fine but logon attempts result in a type mismatch error. This may be a bug.

It is, filed and fixed, thanks.

> 
>Moving on however, idp-process.log indicates c14n subject resolution is not occurring. Have I missed a step?

No, the documentation just isn't clear on something that makes what you're doing much more complex than what you're configuring it to do:

>2015-11-07 21:44:56,430 - DEBUG [net.shibboleth.idp.attribute.resolver.dc.ldap.impl.TemplatedExecutableSearchFilterBuilder:203] - Template text (|(sAMAccountName=$requestContext.principalName)(userPrincipalName=$requestContext.principalName))
> yields (|(sAMAccountName=$requestContext.principalName)(userPrincipalName=$requestContext.principalName))

That's circular, at the moment. You're trying to resolve the value that will actually be put into requestContext.principalName, so by definition you can't be relying on it in the connector that would run to resolve that value.

In fact, by doing the LDAP query there in that way, you should probably just ignore c14n. You've already done the work in your resolver to compensate for the fact that the principal name will be non-uniform.

But if you did want to actually normalize it, you can't just use a simple configuration like that right now. The input data to the c14n step is not a simple name (because if it were you'd be done), it's a Java Subject. You pretty much always end up needing to use a script connector or attribute definition for this particular feature, that's the only built-in way that the Subject could be accessed. It's in a child context:

profileRequestContext.getSubcontext(
	"net.shibboleth.idp.authn.context.SubjectCanonicalizationContext").getSubject()

Inside there you have Principals, and one of them is the value the user supplied (in a UsernamePrincipal).

The real purpose behind this feature is for cases where the input to the process isn't something as simple as what a user enters. Looking up a certificate DN in a database for example.

-- Scott