Hong Ye hy93 at
Mon Feb 12 12:26:35 EST 2018

Thanks Pete. That's the answer I am looking for.

On 2/12/18, 12:13 PM, "Peter Schober" <peter.schober at> wrote:

    * Cantor, Scott <cantor.2 at> [2018-02-12 17:16]:
    > > Thanks Scott. Can I use netid? It is unique and non re-assignable. Then the
    > > value of eduPersonUniqueID will be the same as eduPersonPrincipalName. Is
    > > that fine?
    > That would be a very poor choice unless you never change them.
    If the source identfier is stable (as claimed above) and you've
    already configured persistent NameID support in your IDP using IDPv3's
    conf/ it's simple to also create a
    non-SP-specific version from it as ePUID, e.g.:
    Due to the use of properties for source attribute, salt and scope that
    definition should be copy/paste-able for most IDPv3 instances.
    > Please read
    > That's what
    > you're signing up for and it is very clear about the requirements.
    Once you have ePUID defined in your resolver (with values satisfying
    both ePUID's and subject-id's requirements) it's trivial to also
    release that same value as subject-id, e.g.:
    <AttributeDefinition id="subjectID" xsi:type="Scoped" scope="%{idp.scope}" sourceAttributeID="eduPersonUniqueId">
      <Dependency ref="eduPersonUniqueId" />
      <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:oasis:names:tc:SAML:attribute:subject-id" encodeType="false" />
      <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oasis:names:tc:SAML:attribute:subject-id" friendlyName="subjectID" encodeType="false" />
    Of course all the caveats Scott mentioned said still apply. The above
    is just an example of how to do that if your identifiers are suitable
    and you're willing to create the values dynamically (but consistently).
    For Consortium Member technical support, see
    To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list