PersonImmutableID configuration

[Steve Herrera]

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:
<AttributeEncoder xsi:type="SAML2String" *name="PersonImmutableID"*
  nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
  encodeType="false" relyingParties="ENTITYID_OF_THE_SP" />

What does the (*name="PersonImmutableID"*) 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?

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.

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
https://*hostname*/idp/profile/SAML2/Unsolicited/SSO
?providerId=AudienceURL&target=RelayStateURL

After using the correct URL and making the other suggested changes, it is
working. Thank you.

Steve Herrera
System Administration

On Thu, Oct 8, 2020 at 2:51 AM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Steve Herrera via users <users at shibboleth.net> [2020-10-07 22:23]:
> > One is the attribute type that they require. They call it
> > "PersonImmutableID". I have that being populated with the correct
> > information Employee number as agreed upon but their side views it as
> null.
> > Is there something I need to do to make that attribute immutable?
>
> A name is just a name. AFAICT "PersonImmutableID" is just an
> arbitrary, made-up name for an attribute, used by OneLogin and/or this
> ADP SP you're trying to federate with.
>
> > Here is how I have it defined in attribute-resolver.xml file:
> >
> > <AttributeDefinition xsi:type="Simple" id="PersonImmutableID">
> >
> >         <InputDataConnector ref="myLDAP"
> attributeNames="employeeNumber"/>
> >
> >         <AttributeEncoder xsi:type="SAML1String" name=
> > "urn:mace:dir:attribute-def:employeeNumber" />
> >
> >         <AttributeEncoder xsi:type="SAML2String" name=
> > "urn:oid:2.16.840.1.113730.3.1.3" friendlyName="employeeNumber" />
> >     </AttributeDefinition>
>
> Well, the only thing that says "PersonImmutableID" is the
> internal-to-the-IDP "id" XML-attribute. All the encoders write into
> the SAML are the standard attribute name for employeeNumber (in its
> various name formats).
> So better name this defintion id="employeeNumber", because that's what
> it is.
>
> If you already have such a definition you can remove this new one
> here, as it will be identical in all respects except for the internal
> id. Then add something like this to the existing id="employeeNumber"
> attribute definition (assuming IDPv3), after the other encoders:
>
> <AttributeEncoder xsi:type="SAML2String" name="PersonImmutableID"
>   nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   encodeType="false" relyingParties="ENTITYID_OF_THE_SP" />
>
> Replace "ENTITYID_OF_THE_SP" with the entityID Of the ADP SP you're
> trying to federate with.
>
> > The second part is what they call the "Relay State" url. They provided a
> > URL labeled Relay State but I'm not sure how to configure it.
>
>
> https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration
>
> https://wiki.shibboleth.net/confluence/display/IDP4/UnsolicitedSSOConfiguration
> "SAML 2.0" -> "target" -> "corresponds to RelayState in the SAML 2.0
> protocol"
>
> I.e., you add &target=THE_PROVIDED_URL_AT_THE_SP to your IDP-initated
> URL, replacing "THE_PROVIDED_URL_AT_THE_SP" with the provided URL at
> the SP.
>
> > In my relying-party.xml, I have to configure a url that is labeled
> > "Audience" That is what creates the handshake between them and
> > us.
>
> I don't know what exactly you did in your relying-party.xml but your
> description makes no sense to me. Technical trust comes from
> exchanging metadata (or its content exchanged another way). In
> relying-party.xml you merely need to specify exceptional behaviour
> (which seems to be the norm today, which is somewhat paradox).
> Feel free to post an example for detailed review.
>
> -peter
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20201008/1f3aa5ce/attachment.htm>