PersonImmutableID configuration

[Peter Schober]

* 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