Getting attributes from an OpenAM 10 Idp

[Nate Klingenstein]

Mike,

> I am running Shibboleth 2.x on IIS.
>
> I am trying to get attributes to pass from an Idp based on the  
> OpenAM 10 service.  We connect just fine.  Just trying to get the  
> attributes to pass through...
>
> They are passing a standard LDAP mail attribute.

This isn't really "standard".  The name is hopelessly not unique.  The  
proper unique name for the mail attribute would be name="urn:oid:0.9.2342.19200300.100.1.3 
", friendlyName="mail", and a nameFormat of NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri 
".

But it may not be too feasible to make this change on their end, so to  
make a change on yours, read on.

> From their assertion:
>
> <saml:AttributeStatement>
> <saml:Attribute Name="mail">
> <saml:AttributeValue xmlns:xs="http://www.w3.org/ 2001/XMLSchema"  
> xmlns:xsi="http://www.w3.org/ 2001/XMLSchema-instance"  
> xsi:type="xs:string">auser@ someplace.com</saml: AttributeValue>
> </saml:Attribute>
> </saml:AttributeStatement>
>
> And their configuration defines mail as this:
>
> <saml:Attribute Name="mail">
> <saml:AttributeValue xmlns:xs="http://www.w3.org/ 2001/XMLSchema"  
> xmlns:xsi="http://www.w3.org/ 2001/XMLSchema-instance"  
> xsi:type="xs:string">cayetano@ adobe.com</saml: AttributeValue>
> </saml:Attribute>
>
> Now I have mail defined as this (default definition that came with  
> Shib):
>
>     <Attribute name="urn:mace:dir:attribute- def:mail" id="mail"/>
>
> I am going to guess that the mace urn is not going to fly for them  
> on this.  For another customer I defined an attribute for them like  
> this:
>      <Attribute name="qcmail" nameFormat="urn:oasis:names: tc:SAML: 
> 2.0:attrname-format: basic" id="qcmail">
> <AttributeDecoder xsi:type=" StringAttributeDecoder"  
> caseSensitive="false"/>
> </Attribute>
>
> And that worked fine.  I am guessing that I will need to do a  
> similar definition for mail (non MACE) for this to pass through.  My  
> questions are:
>
> Is the MACE name indeed what prevents the attribute from passing?   
> Since they would not match that name value on their side...

It's not that the MACE name is "preventing" an attribute from  
passing.  The SP is receiving an attribute with a name and nameFormat  
that it doesn't recognize and it doesn't know how to handle it.

> Next question (assuming that the MAC name is not going to fly...):
>
> If I re-define, let's say, mail for example and I do it like this:
>
>      <Attribute name="mail" nameFormat="urn:oasis:names: tc:SAML: 
> 2.0:attrname-format: basic" id="mail">
> <AttributeDecoder xsi:type=" StringAttributeDecoder"  
> caseSensitive="false"/>
> </Attribute>

This is close, but with no nameFormat in the attribute, I believe  
you'll want :attrname-format:undefined rather than :attrname- 
format:basic.

> Will the duplicate ID value of 'mail' conflict with the MACE version  
> of the attribute?

The ID determines which header/environment variable the attribute is  
placed into and how it is known to the rest of the SP.  You may map  
many SAML attributes to one internal ID, or each SAML attribute to its  
own internal ID; pick the behavior that you desire.

Take care,
Nate.