Attributes being removed from SAML1 Service Provider because they cannot be encoded.

[Tom Poage]

NIH wants basically the same as NSF (research.gov) for SAML 1, in that
they want:

1. Attribute push. Probably easiest to create a <RelyingParty>, e.g.

> <RelyingParty id="their entityID" provider="your entityID" defaultSigningCredentialRef="your credential ID">
>     <ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement="true"/>
> </RelyingParty>

2. ePPN labeled with its OID. Perhaps easiest to create a custom ePPN
definition for them.

> <resolver:AttributeDefinition id="eduPersonPrincipalName-NIH" xsi:type="Prescoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="your source attr">
>     <resolver:Dependency ref="your source identifier" />
>     <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" scopeType="inline" />
>     <resolver:AttributeEncoder xsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" scopeType="inline" />
> </resolver:AttributeDefinition>

> <AttributeFilterPolicy id="NSF">
>     <PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="their entityID"/>
...
>     <AttributeRule attributeID="eduPersonPrincipalName-NIHNSF">
>         <PermitValueRule xsi:type="basic:ANY" />
>     </AttributeRule>
...

As far as I know, NIH doesn't support SAML 2 (yet).

Tom.

On 08/02/2011 10:16 AM, Khanna, Sumit (khannast) wrote:
> Sorry, I'm a little confused. So using SAML1, are SPs supposed to pull
> attributes via the backchannel (is pushing not supported at all in SAML1?) I
> contacted support for NIH (the SP) and was told "our federation product is
> CA siteminder and this is not capable of pulling SAML1 attributes through
> backchannel."
> 
> I was also a little confused because they required the following attributes
> to be released:
> 
> urn:mace:dir:attribute-def:eduPersonPrincipalName,
> urn:mace:dir:attribute-def:mail, urn:mace:dir:attribute-def:sn,
> urn:mace:dir:attribute-def:givenName, urn:oid:1.3.6.1.4.1.5923.1.1.1.6
> 
> In our attribute-resolver, we have all the urn:mace.. for the SAML1String
> and SAML1XMLObject types and we use the OID for all the SAML2 types. The OID
> 1.3.6.1.4.1.5923.1.1.6 already represents the eduPersonPrincipalName, so I
> asked why it was included twice and was told:
> 
>>> Our product also cannot parse the attribute
>>> urn:mace:dir:attribute-def:eduPersonPrincipalName as there is a scope
>>> parameter attached to it so the new attribute
>>> urn:oid:1.3.6.1.4.1.5923.1.1.1.6 was designed by shibb developers which
> has
>>> the value of scope as in-line. 
>>>
>>> The specific requirement for the shibb IPDs is to release the attribute
>>> urn:oid:1.3.6.1.4.1.5923.1.1.1.6 to use our service provider.
> 
> I'm kinda lost here. Do I define a new parameter as a SAML1String using the
> OID and how do I push those attributes via SAML1?
> 
> Sumit