REDACTED Re: inconsistent attribute release

Liam Hoekenga liamr at umich.edu
Wed Oct 19 14:56:09 BST 2011


Nevermind.

I guess I am seeing what I need on the SP.

uApprove shows the local name (e.g. dartSurname) instead of the name  
used in the encoder (e.g. sn).  I thought it was otherwise.  The SP is  
seeing the value with the expected attribute name.

Liam


Quoting Liam Hoekenga <liamr at umich.edu>:

> We've enabled guest access to our IdP in our dev environment.  The only
> attribute we're releasing is email, because that's the only thing we
> really know about them.  So, we've have this attribute definition..
>
>    <resolver:AttributeDefinition id="cosignFriendEmail"  
> xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
>      <resolver:AttributeEncoder xsi:type="SAML1String"  
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"  
> name="urn:mace:dir:attribute-def:mail" />
>      <resolver:AttributeEncoder xsi:type="SAML2String"  
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"  
> name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="email" />
>    </resolver:AttributeDefinition>
>
> And a corresponding attribute filter..
>
>    <AttributeFilterPolicy id="cosignFriend">
>      <PolicyRequirementRule xsi:type="basic:AND">
>        <basic:Rule xsi:type="basic:AttributeValueString"  
> attributeID="umichCosignFactor" value="friend"/>
>        <basic:Rule xsi:type="saml:AttributeRequesterInEntityGroup"  
> groupID="urn:mace:umich.edu:shibboleth:federation" />
>      </PolicyRequirementRule>
>
>      <AttributeRule attributeID="cosignFriendEmail">
>        <PermitValueRule xsi:type="basic:ANY" />
>      </AttributeRule>
>    </AttributeFilterPolicy>
>
> This is working exactly how we want it it.  cosignFriendEmail gets
> released as "mail".  uApprove sees it as mail.  Everything's happy.
>
> I'm trying to set up a similar situation for a specific service provider.
> In this case, we need to be able choose from two possible values for an
> attribute, so we've got a scripted attribute..
>
>    <resolver:AttributeDefinition xsi:type="Script"  
> xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="dartSurname">
>      <resolver:Dependency ref="mcommDir" />
>      <resolver:Dependency ref="mcommReg" />
>      <resolver:AttributeEncoder xsi:type="enc:SAML1String"  
> name="urn:mace:dir:attribute-def:sn" />
>      <resolver:AttributeEncoder xsi:type="enc:SAML2String"  
> name="urn:oid:2.5.4.4" friendlyName="sn" />
>       
> <ScriptFile>/home/liamr/shibboleth-idp/script/dartSurname.js</ScriptFile>
>    </resolver:AttributeDefinition>
>
> The meat of which looks like..
>
>    dartSurname = new BasicAttribute("dartSurname");
>
>    if (typeof(umichDisplaySN) != 'undefined') {
>      dartSurname.getValues().add(umichDisplaySN.getValues().get(0));
>    } else if (typeof(umichRegDisplaySurname) != 'undefined') {
>      dartSurname.getValues().add(umichRegDisplaySurname.getValues().get(0));
>    }
>
> This, too, works fine.
>
> The problem is when we get to attribute release. Both uApprove and the SP
> sees this attribute as "dartSurname", rather than "sn".
>
> I'd thought that by using the same attribute encoders used by the
> "normal" sn attribute, that when the attribtue got released it would be
> seen as "sn" (which seems to be what happened with cosignFriendMail /
> mail).  dartSurname is the only attribute using the sn encoders that
> this SP sees.
>
> Have I misunderstood how this (is supposed to?) work?  Does it work
> differently with scripted attributes?
>
> thanks!
> Liam
> --
> To unsubscribe from this list send an email to  
> users-unsubscribe at shibboleth.net
>
> !DSPAM:4e9db2be235535080613039!
>
>
>
>




More information about the users mailing list