Adding custom attributes based on entityID

[Sonny Garcia]

A percentage of the clients we integrate with prefer to use one of their own custom attributes for user identification as opposed to using the EPPN.  In order to abstract the burden of treating different attribute values as the user ID in our application, we decided to define every custom attribute with the same id and give preference to its usage over the EPPN; see example below.


    <!-- =========== Custom Client ID Attributes ========== -->

    <!-- university A -->
    <Attribute name="urn:mace:university.edu:edimi:attributes:universityPPID" id="custom-client-id">
        <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/>
    </Attribute>
    <!-- university B -->
    <Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="custom-client-id"/>
    <!-- university C -->
    <Attribute name="urn:oid:1.3.6.1.4.1.6464.1.1.1.2" id="custom-client-id"/>
    <!-- university D -->
    <Attribute name="urn:mace:dir:attribute-def:universityid" id="custom-client-id"/>
    <Attribute name="urn:oid:1.3.6.1.4.1.14395.1.1.1.1.5"   id="custom-client-id"/>


We now realize that this approach will not work long-term and can cause us to potentially use the wrong attribute for identification when integrating with new IdPs (e.g. they release another, unrelated attribute with the same name as one of the attribute statements listed above) .

That being said, the above approach of using the same “id” for all custom attributes will only work if we have a way to map/extract custom attributes based on the issuer (entityID).  This will guarantee that one IdP does not see the “custom-client-id” of another.  It looks like we can selectively PERMIT or DENY attribute propagation using an "Attribute Filter Policy,” but that’s not what we’re looking for in this case.

Is this at all possible or is it required (or even best-practice) to define each custom attribute with a unique “id” ?


Sonny R Garcia
IT Operations Lead | OrgSync, Inc.
www.orgsync.com<http://www.orgsync.com/>






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141103/a0f67269/attachment-0001.html