<div dir="ltr"><font face="arial, sans-serif">Thank you. I made those changes and put employeeNumber in my attribute-filter.xml file to be released to ADP. Yes, we are currently on 3.x series. We have a window of time to upgrade that to 4.X in December. For the attribute-resolver file:</font><div><font face="arial, sans-serif"><AttributeEncoder xsi:type="SAML2String" <b>name="PersonImmutableID"</b><br>  nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"<br>  encodeType="false" relyingParties="ENTITYID_OF_THE_SP" /></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">What does the (<b>name="PersonImmutableID"</b>) do in this instance? Is that used internally like the ID field or is it external and translates my ID of employeeNumber to PersonImmutableID for the SP?  </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Getting the metadata from them was like pulling teeth. They kept telling me that is not their standard setup method. I think I read I could have created the metadata to be used with them, but I'm not sure how to go about that. They finally did get me the metadata file I was needing. From there is where I saw that the entity-id I needed is what they call the audience url.  When I mentioned the handshake, is because the documentation said an entry was required there. Without it, I would try the UnsolicatedSSO url to get me there and the SP displayed a large "Handshake" failure. </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Just so if anyone else is having trouble with a similar SP. The audience URL is the entityID, the RelayState is part of the URL the enduser hits. So <span style="color:rgb(23,43,77);font-size:14px">https://<em style="">hostname</em>/idp/profile/SAML2/Unsolicited/SSO</span>?providerId=AudienceURL&target=RelayStateURL</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">After using the correct URL and making the other suggested changes, it is working. Thank you.</font></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><p><span style="font-family:Arial,sans-serif;color:rgb(31,73,125)"><font size="1">Steve Herrera<br></font></span><span style="font-family:Arial,sans-serif;color:rgb(31,73,125)"><font size="1">System Administration<br></font></span></p></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 8, 2020 at 2:51 AM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Steve Herrera via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> [2020-10-07 22:23]:<br>
> One is the attribute type that they require. They call it<br>
> "PersonImmutableID". I have that being populated with the correct<br>
> information Employee number as agreed upon but their side views it as null.<br>
> Is there something I need to do to make that attribute immutable?<br>
<br>
A name is just a name. AFAICT "PersonImmutableID" is just an<br>
arbitrary, made-up name for an attribute, used by OneLogin and/or this<br>
ADP SP you're trying to federate with.<br>
<br>
> Here is how I have it defined in attribute-resolver.xml file:<br>
> <br>
> <AttributeDefinition xsi:type="Simple" id="PersonImmutableID"><br>
> <br>
>         <InputDataConnector ref="myLDAP" attributeNames="employeeNumber"/><br>
> <br>
>         <AttributeEncoder xsi:type="SAML1String" name=<br>
> "urn:mace:dir:attribute-def:employeeNumber" /><br>
> <br>
>         <AttributeEncoder xsi:type="SAML2String" name=<br>
> "urn:oid:2.16.840.1.113730.3.1.3" friendlyName="employeeNumber" /><br>
>     </AttributeDefinition><br>
<br>
Well, the only thing that says "PersonImmutableID" is the<br>
internal-to-the-IDP "id" XML-attribute. All the encoders write into<br>
the SAML are the standard attribute name for employeeNumber (in its<br>
various name formats).<br>
So better name this defintion id="employeeNumber", because that's what<br>
it is.<br>
<br>
If you already have such a definition you can remove this new one<br>
here, as it will be identical in all respects except for the internal<br>
id. Then add something like this to the existing id="employeeNumber"<br>
attribute definition (assuming IDPv3), after the other encoders:<br>
<br>
<AttributeEncoder xsi:type="SAML2String" name="PersonImmutableID"<br>
  nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"<br>
  encodeType="false" relyingParties="ENTITYID_OF_THE_SP" /><br>
<br>
Replace "ENTITYID_OF_THE_SP" with the entityID Of the ADP SP you're<br>
trying to federate with.<br>
<br>
> The second part is what they call the "Relay State" url. They provided a<br>
> URL labeled Relay State but I'm not sure how to configure it.<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration</a><br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP4/UnsolicitedSSOConfiguration" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP4/UnsolicitedSSOConfiguration</a><br>
"SAML 2.0" -> "target" -> "corresponds to RelayState in the SAML 2.0 protocol"<br>
<br>
I.e., you add &target=THE_PROVIDED_URL_AT_THE_SP to your IDP-initated<br>
URL, replacing "THE_PROVIDED_URL_AT_THE_SP" with the provided URL at<br>
the SP.<br>
<br>
> In my relying-party.xml, I have to configure a url that is labeled<br>
> "Audience" That is what creates the handshake between them and<br>
> us.<br>
<br>
I don't know what exactly you did in your relying-party.xml but your<br>
description makes no sense to me. Technical trust comes from<br>
exchanging metadata (or its content exchanged another way). In<br>
relying-party.xml you merely need to specify exceptional behaviour<br>
(which seems to be the norm today, which is somewhat paradox).<br>
Feel free to post an example for detailed review.<br>
<br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>