ECMA to access SubjectCanonicalizationContext in Resolver

[Michael A Grady]

> On Nov 11, 2015, at 4:19 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
> 
>> Rod might have a view on whether it's possible to adjust the behavior of
>> scripted attributes or connectors to not return anything with an empty
> value set
>> (as distinct from empty values).
> 
> Would there not be backward compatibility issues?  Or do you mean a "no
> attribute if no values" setting.  Not sure I like that for the attribute
> resolver ("why do I not get an attribute if I run this scripted attribute",
> but it makes sense for the dataconnector.
> 
> Beyond that I'd need to see what the code looks like.
> 
> So I don't lose it can someone add a RFI?
> 

I'll do that, and the Issue for the bug around error handling if connector attribute dependency has no values.

But in the light of a new day, I realize there is another option to how I configured this. That would be, if that subject c14n context is "no longer around" (null from trying to access that subContext), then set this attribute value (my rawUsername) to the requestContext.principalName. Then I don't need two configs of the LDAP DC, just one, which can be doing the lookup consistently on the "first value" of rawUsername. (Although then that latter variable name really needs another name, because the first time it is that, but the 2nd time thru at standard resolution flow time, it becomes the canonicalized principal.)

What would be the "state" of requestContext.principalName when I pass thru at c14n time? Is it undefined until after c14n completes?


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