Adding custom attributes based on entityID

[Peter Schober]

* Sonny Garcia <sonny at orgsync.com> [2014-11-03 21:09]:
> 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.

That "burden" is a switch statement in one place of your code, with
the rest of the code re-using your internal abstraced name, right?

Also note that you can abstract out multiple attribute names using the
SP's REMOTE_USER precedence list (assumes different internal attribute
names for different attributes).

> 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) .

If everyone used unique /or/ clearly defined atttribute names that
shouldn't be an issue. urn:oid:0.9.2342.19200300.100.1.1 is a userId
no matter what IDP sent it, or the IDP is sending wrong data (which is
different from saying each IDP sends different attributes).

> 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.

The SP's attribute policy will allow you to say "I only accept
attribute X from IDP Y", which seems to be just what you want. If
you're saying the policy operates on internal names (which is correct)
and therefore you cannot distinuish different attributes because you
chose to map different attributes of all kinds into the same internal
name in the step before... well, don't do that.

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

If you first map all attributes into a single internal name you cannot
treat them differently in the policy. So if you really wanted to go
the way of filtering attributes based on the issuer, you'd have to map
them unto different ids in the mapper.
Personally I'd map differnt attributes unto different internal names
and the semantically same attribute (going by different names) into
the same internal name. You're then free to do additional filtering,
or not, depending on the uniqueness/chaos of the data you decided to
accept.
Then either iterate over the list of all possible attributes in your
own code once, and re-use everywhere else, or use the SP's
functionality to do just that.
-peter