scoped NameID SAML subject

[David Bantz]

Attempting to build a NameID in the SAML subject to meet a vendor requirement.
The following uses and inserts the right identifier, but despite being based on ePPN,
appears in the SAML assertion subject un-scoped: If ePPN is george-TNFzNwJ3FIT/***@public.gmane.org, this
uses the NameID of george in subject portion of the SAML. To meet vendor requirement,
I need the scoped value george-TNFzNwJ3FIRfmgfxC/sS/***@public.gmane.org Is there a simple way to do that?

<!-- Okta requires something like ePPN in the SAML Subject -->
<resolver:AttributeDefinition
id="oktanameid"
xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="eduPersonPrincipalName"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:resolver="urn:mace:shibboleth:2.0:resolver">
<resolver:Dependency ref="myLDAP" />
<resolver:Dependency ref="eduPersonPrincipalName" />
<resolver:AttributeEncoder
xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
<resolver:AttributeEncoder
xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
friendlyName="username" />
</resolver:AttributeDefinition>

David Bantz
U Alaska

[Cantor, Scott]

Post by David Bantz
Attempting to build a NameID in the SAML subject to meet a vendor requirement.
The following uses and inserts the right identifier, but despite being based on ePPN,
appears in the SAML assertion subject un-scoped: If ePPN is
uses the NameID of george in subject portion of the SAML. To meet vendor requirement,
that?

Not simple, you'd have to get an attribute defined that's string-valued
with both parts included, and attach the encoder to that. Basically what
you'd do with mail.

I fixed this in v3 when the new portion of the IdP is used to generate
NameIDs instead of the resolver.

-- Scott

[David Bantz]

To tie up this thread, I was able to “build” and attribute syntactically identical to ePPN
that is released as the domain-qualified NameID in the Subject of the SAML assertion using
the definition below. I’m not proud of it, but it seems to do the job.

<!— Create NameID like ePPN for the SAML Subject -->
<resolver:AttributeDefinition xmlns="urn:mace:shibboleth:2.0:resolver:ad"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:resolver="urn:mace:shibboleth:2.0:resolver"
id="oktanameid" xsi:type="Script"
sourceAttributeID="UASystemID">
<resolver:Dependency ref="myLDAP"/>
<resolver:AttributeEncoder xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
xsi:type="SAML2StringNameID"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
importPackage(Packages.org.slf4j);

if (null == oktanameid) {oktanameid = new BasicAttribute("oktanameid");}
oktausername = UASystemID.getValues().get(0);
oktanameid.getValues().add(oktausername + "@alaska.edu");

]]></Script>
</resolver:AttributeDefinition>

Post by Cantor, Scott

Post by David Bantz
Attempting to build a NameID in the SAML subject to meet a vendor requirement.
The following uses and inserts the right identifier, but despite being based on ePPN,
uses the NameID of george in subject portion of the SAML. To meet vendor requirement,
<!-- Okta requires something like ePPN in the SAML Subject -->
<resolver:AttributeDefinition
id="oktanameid"
xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="eduPersonPrincipalName"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:resolver="urn:mace:shibboleth:2.0:resolver">
<resolver:Dependency ref="myLDAP" />
<resolver:Dependency ref="eduPersonPrincipalName" />
<resolver:AttributeEncoder
xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
<resolver:AttributeEncoder
xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
friendlyName="username" />
</resolver:AttributeDefinition>

Not simple, you'd have to get an attribute defined that's string-valued
with both parts included, and attach the encoder to that. Basically what
you'd do with mail.
I fixed this in v3 when the new portion of the IdP is used to generate
NameIDs instead of the resolver.
-- Scott
--

[Tompkins,Charles R]

I had to do a few of these recently, myself. I know you're working with a vendor, but I personally wouldn't represent the value of this eppn-based nameid as transient.

-Charles


-----Original Message-----

From: David Bantz [***@alaska.edu]
Received: Friday, 29 Aug 2014, 6:26PM
To: Shib Users [***@shibboleth.net]
Subject: Re: scoped NameID SAML subject



To tie up this thread, I was able to “build” and attribute syntactically identical to ePPN

that is released as the domain-qualified NameID in the Subject of the SAML assertion using

the definition below. I’m not proud of it, but it seems to do the job.








<!— Create NameID like ePPN for the SAML Subject -->


<resolver:AttributeDefinition xmlns="urn:mace:shibboleth:2.0:resolver:ad"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


xmlns:resolver="urn:mace:shibboleth:2.0:resolver"


id="oktanameid"
xsi:type="Script"


sourceAttributeID="UASystemID">


<resolver:Dependency
ref="myLDAP"/>


<resolver:AttributeEncoder
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"



xsi:type="SAML2StringNameID"



nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>


<Script><![CDATA[


importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);


importPackage(Packages.org.slf4j);







if (null == oktanameid) {oktanameid = new BasicAttribute("oktanameid");}


oktausername = UASystemID.getValues().get(0);


oktanameid.getValues().add(oktausername + "@alaska.edu");







]]></Script>


</resolver:AttributeDefinition>








On Thu, 28 Aug 2014, at 13:53 , Cantor, Scott <***@osu.edu> wrote:


On 8/28/14, 5:48 PM, "David Bantz" <***@alaska.edu> wrote:













Attempting to build a NameID in the SAML subject to meet a vendor requirement.

The following uses and inserts the right identifier, but despite being based on ePPN,

appears in the SAML assertion subject un-scoped: If ePPN is ***@my.domain, this

uses the NameID of george in subject portion of the SAML. To meet vendor requirement,

I need the scoped value ***@my.domaim. Is there a simple way to do that?








<!-- Okta requires something like ePPN in the SAML Subject -->


<resolver:AttributeDefinition


id="oktanameid"


xsi:type="Simple"


xmlns="urn:mace:shibboleth:2.0:resolver:ad"


sourceAttributeID="eduPersonPrincipalName"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


xmlns:resolver="urn:mace:shibboleth:2.0:resolver">


<resolver:Dependency ref="myLDAP" />


<resolver:Dependency ref="eduPersonPrincipalName" />


<resolver:AttributeEncoder


xsi:type="SAML2StringNameID"


xmlns="urn:mace:shibboleth:2.0:attribute:encoder"


nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />


<resolver:AttributeEncoder


xsi:type="SAML2String"


xmlns="urn:mace:shibboleth:2.0:attribute:encoder"


name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"


friendlyName="username" />


</resolver:AttributeDefinition>









Not simple, you'd have to get an attribute defined that's string-valued

with both parts included, and attach the encoder to that. Basically what

you'd do with mail.



I fixed this in v3 when the new portion of the IdP is used to generate

NameIDs instead of the resolver.



-- Scott

[Cantor, Scott]

I had to do a few of these recently, myself. I know you're working with a
vendor, but I personally wouldn't represent the value of this eppn-based
nameid as transient.

No, I didn't notice. The "proper" way is to use a Format value equal to
the urn:oid name of the attribute (EPPN's in this case). The vendor
probably won't notice or care, which is another reason to try that first.

-- Scott