attribute resolver script

[Andrew Morgan]

On Tue, 22 Nov 2016, Michael A Grady wrote:

>
>> On Nov 22, 2016, at 3:15 PM, Andrew Morgan <morgan at orst.edu> wrote:
>>
>> Here is a weird example to make sure we always release a firstname to Webex.  Givenname is not a required attribute in LDAP, so sometimes we don't populate it, but Webex requires a value.  We return "." when givenname is empty.
>>
>>  <resolver:AttributeDefinition xsi:type="ad:Mapped" id="webex_firstname" sourceAttributeID="givenName">
>>      <resolver:Dependency ref="ONIDLDAP" />
>>      <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="firstname" />
>>      <ad:DefaultValue>.</ad:DefaultValue>
>>      <ad:ValueMap>
>>          <ad:ReturnValue>$1</ad:ReturnValue>
>>          <ad:SourceValue>(.+)</ad:SourceValue>
>>      </ad:ValueMap>
>>  </resolver:AttributeDefinition>
>
> But the above actually working is illustrative of the "confusion". 
> DefaultValue should, according to the documentation, only be returned 
> for a value in the attribute that does *not* match one of the ValueMaps. 
> But if the attribute is not populated in LDAP, there are no values of 
> it, and thus nothing should be returned from this. It should not return 
> the '.' .
>
> From the documentation:
>
> <DefaultValue> 0 or 1 Describes the action to be taken if any input 
> value does not match one of the <ValueMap> SourceValue elements that 
> follow.

Interesting!  I see the distinction.  We are definitely depending on the 
current behavior, which appears to create a value (the default) when no 
input value is provided.  That is pretty counter-intuitive (bug?) if the 
Mapped code is working on a list of values.

Is there another way to apply a default value for an attribute that 
doesn't involve a Scripted attribute definition?  I've been avoiding 
Scripted attributes so far given the ugliness of the Java engine stuff.

Thanks,
 	Andy