Adding custom attributes based on entityID
sonny at orgsync.com
Mon Nov 3 16:24:50 EST 2014
On Nov 3, 2014, at 2:45 PM, Peter Schober <peter.schober at univie.ac.at<mailto:peter.schober at univie.ac.at>> wrote:
* Sonny Garcia <sonny at orgsync.com<mailto: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).
The docs (https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess) seem to indicate that REMOTE_USER can be unreliable, especially in the case when IdPs supply on a single attribute for granting access; this is the case with some of our integrations.
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).
I think that relying on the our clients to define unique attributes in all cases will only end up landing us in trouble at some point in the future. Secondly, since we have little to no control over any IdP's attribute release policy, for us to make that assumption would prove far to brittle in my opinion.
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.
While I understand the attribute policy and think it's useful, I don’t think it’s what we need in our case. I’m really interested in knowing if we can define a single attribute differently based on the issuer.
-> Define attribute X as Y if from IdP A
-> Define attribute X as Z if from IdP B
-> ….and so on
Unfortunately, I do not think this operation is supported.
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
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.
I think our only option is to re-define these attributes with unique IDs and redesign our code to selectively choose which header value to pluck based on some dynamic, persistent configuration; see below.
-> use header X as an ID with school A
-> use header Y as an ID with school B
-> ….and so on
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users