Subject Canonicalization problem

[Michael A Grady]

> On Nov 9, 2015, at 9:03 AM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
> 
> On 11/8/15, 9:34 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:
> 
> 
> 
>> Would that be something like (building on what you sent before, and delving into the Java code around this:
>> 
>> userProvidedUsername = profileRequestContext.getSubcontext(
>> 	"net.shibboleth.idp.authn.context.SubjectCanonicalizationContext").getSubject().getPrincipals(UsernamePrincipal.class).iterator().next().getname();
>> Scripted.addValue( userProvidedUsername );
> 
> Yes, imports and such aside, and without any error handling.

I was thinking of error handling, and what would be appropriate to do here? If the above didn't succeed in delivering an actual value, what should one do? Theoretically, you have Simple to still fall back on, and its own error handling if that doesn't succeed, but presumably it is going to try and access the same value as this. And there is the matter of the data connector dependent on this Scripted attribute and what it's error behavior would be if no attribute. Any recommendations?

> 
> I thought about whether it might be worth trying to build something to automate that, but it seemed a little pointless. I also considered whether we should be populating principalName in the resolution context with that value for this particular resolver run, but it seems like a bad idea to contaminate the semantics of that property.

That would certainly make it simpler, but yes, on reflection it would seem wrong to pre-populate the property that the c14n process is going to result in with a value before that; does indeed seem circular. On the other hand, you could argue that would be like just automatically running the Simple flow, but then giving a chance to override that choice by immediately trying a different flow. The downside to that, I guess, is that if that follow-on fails, you don't then have Simple to fall back on. (Maybe Simple becomes an optional "initial c14n flow", analogous to the "initial authn flow", that one can configure? For that matter, could one do that now with just a bit of c14n flow configuration, and not fall back on defining a scripted attribute/data connector dependent on that?)


--
Michael A. Grady
IAM Architect, Unicon, Inc.