help with SAML NameID putting different values when integrating more than 2 tenants for Workday
Alvarez, Dyana I
d.alvarez2 at miami.edu
Wed Mar 4 14:01:37 EST 2015
Hi,
I have a question regarding the SAML and Shibboleth.
I am integrating Workday with Shibboleth for SSO.
We have 4 tenants with them with different cert keys.
When I integrate any two tenants, it works fine but when I integrate the third and fourth tenant all of them break.
This is what's happening:
When I integrate Tenants 1 and 2, the userID is readable in the NameID SAML for both Tenants:
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="https://cas.cgcent.miami.edu/idp/shibboleth"
>dalvarez</saml2:NameID>
When I aggregate another tenant, I get in the SAML a series of numbers and letters instead of the userID:
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://cas.cgcent.miami.edu/idp/shibboleth"
>_dba6612315abd519cf6044af38a84074</saml2:NameID>
The reason being, I have a filter that says do not release to Workday if the userID is not in the group workday_1 and so forth (Tenant 1 has its own group called workday_1, Tenant 2 has its own group called workday_2 in AD, etc.
This is my filter (if the user is not part of the group for that specific tenant, then it will not release userIDWorkday:
<afp:AttributeFilterPolicy id="releaseAttributesToWDTenant1">
<afp:PolicyRequirementRule xsi:type="basic:AND">
<basic:Rule xsi:type="basic:AttributeRequesterString" value=" http://www.wd.com/impl1/" />
<basic:Rule xsi:type="basic:AttributeValueString" attributeID=" allowUM1" value="member" />
</afp:PolicyRequirementRule>
<afp:AttributeRule attributeID=" userIDWorkday ">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
<afp:AttributeFilterPolicy id="releaseAttributesToWDTenant2">
<afp:PolicyRequirementRule xsi:type="basic:AND">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://www.wd.com/impl2/" />
<basic:Rule xsi:type="basic:AttributeValueString" attributeID="allowUM2" value="member" />
</afp:PolicyRequirementRule>
<afp:AttributeRule attributeID="userIDWorkday">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
And this is my userIDWorkday resolver configuration ( I have it for both tenant 1 and 2):
<!-- userid realeased as Name ID to workday tenant 1-->
<resolver:AttributeDefinition xsi:type="ad:Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="allowUM2">
<resolver:Dependency ref="MyAD" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
<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.1" friendlyName="eduPersonAffiliation" />
<!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed -->
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
// Create attribute to be returned from definition
allowUM1 = new BasicAttribute("allowUM1");
// If the user has group membership
if (typeof memberOf != "undefined" && memberOf != null ){
for (i=0; memberOf != null && i < memberOf.getValues().size(); i++) {
value = memberOf.getValues().get(i).toLowerCase();
if (value.contains("cn=workday_1,cn=users,dc=dstimer,dc=miami,dc=edu")) {
allowUM1.getValues().add("member");
break;
}
}
}
]]></Script>
</resolver:AttributeDefinition>
<!-- userid realeased as Name ID to workday tenant 2-->
<resolver:AttributeDefinition xsi:type="ad:Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="allowUM2">
<resolver:Dependency ref="MyAD" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
<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.1" friendlyName="eduPersonAffiliation" />
<!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed -->
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
// Create attribute to be returned from definition
allowUM2 = new BasicAttribute("allowUM2");
// If the user has group membership
if (typeof memberOf != "undefined" && memberOf != null ){
for (i=0; memberOf != null && i < memberOf.getValues().size(); i++) {
value = memberOf.getValues().get(i).toLowerCase();
if (value.contains("cn=workday_2,cn=users,dc=dstimer,dc=miami,dc=edu")) {
allowUM2.getValues().add("member");
break;
}
}
}
]]></Script>
</resolver:AttributeDefinition>
And the userid is released as nameid unspecified format
<!-- userid realeased as Name ID-->
<resolver:AttributeDefinition id="userIDWorkday" xsi:type="ad:Simple" sourceAttributeID="sAMAccountName">
<resolver:Dependency ref="MyAD" />
<resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
</resolver:AttributeDefinition>
I guess my question is when I add a new tenant why does it add the series of numbers to the SAML's nameID portion as shown above.
It's not that the redirects don't work, it's the fact that once the user has authenticated with SSO, it redirects to workday with a series of numbers in the name ID.
We ruled out the fact that it could be encrypted because I have added.
<!-- Tenant1-->
<rp:RelyingParty id=" http://www.wd.com/impl1/"
provider="https://auth.cgtimer.domainmi.edu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredentialInCommon">
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" signResponses="always" includeAttributeStatement="true"/>
</rp:RelyingParty>
<!-- Tenant1-->
<rp:RelyingParty id=" http://www.wd.com/impl2/"
provider="https://auth.cgtimer.domainmi.edu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredentialInCommon">
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" signResponses="always" includeAttributeStatement="true"/>
</rp:RelyingParty>
If anyone please can have some insight on why this is happening.
NameID's in the SAML shows okay when 2 or less tenants are integrated.
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="https://cas.cgcent.miami.edu/idp/shibboleth"
>dalvarez</saml2:NameID>
When I aggregate another tenant, I get in the SAML a series of numbers and letters instead of the userID when I test with the same user:
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://cas.cgcent.miami.edu/idp/shibboleth"
>_dba6612315a345345sdf2343af38a84074</saml2:NameID>
Thank you, I'd appreciate any help please.
Diana
More information about the users
mailing list