eduPersonUniqueID

[Hong Ye]

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

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

    * Cantor, Scott <cantor.2 at osu.edu> [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/saml-nameid.properties it's simple to also create a
    non-SP-specific version from it as ePUID, e.g.:
    https://wiki.univie.ac.at/display/federation/IDP+3+Attribute+resolution#IDP3Attributeresolution-eduPersonUniqueID
    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
    > https://wiki.oasis-open.org/security/SAMLSubjectIDAttr. 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" />
    </AttributeDefinition>
    
    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).
    
    HTH,
    -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