<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 3, 2014, at 2:45 PM, Peter Schober <<a href="mailto:peter.schober@univie.ac.at" class="">peter.schober@univie.ac.at</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">* Sonny Garcia <<a href="mailto:sonny@orgsync.com" class="">sonny@orgsync.com</a>> [2014-11-03 21:09]:<br class="">
<blockquote type="cite" class="">A percentage of the clients we integrate with prefer to use one of<br class="">
their own custom attributes for user identification as opposed to<br class="">
using the EPPN. In order to abstract the burden of treating<br class="">
different attribute values as the user ID in our application, we<br class="">
decided to define every custom attribute with the same id and give<br class="">
preference to its usage over the EPPN; see example below.<br class="">
</blockquote>
<br class="">
That "burden" is a switch statement in one place of your code, with<br class="">
the rest of the code re-using your internal abstraced name, right?<br class="">
<br class="">
Also note that you can abstract out multiple attribute names using the<br class="">
SP's REMOTE_USER precedence list (assumes different internal attribute<br class="">
names for different attributes).<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>The docs (<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess" class="">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess</a>) 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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">We now realize that this approach will not work long-term and can<br class="">
cause us to potentially use the wrong attribute for identification<br class="">
when integrating with new IdPs (e.g. they release another, unrelated<br class="">
attribute with the same name as one of the attribute statements<br class="">
listed above) .<br class="">
</blockquote>
<br class="">
If everyone used unique /or/ clearly defined atttribute names that<br class="">
shouldn't be an issue. urn:oid:0.9.2342.19200300.100.1.1 is a userId<br class="">
no matter what IDP sent it, or the IDP is sending wrong data (which is<br class="">
different from saying each IDP sends different attributes).<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">That being said, the above approach of using the same “id” for all<br class="">
custom attributes will only work if we have a way to map/extract<br class="">
custom attributes based on the issuer (entityID). This will<br class="">
guarantee that one IdP does not see the “custom-client-id” of<br class="">
another. It looks like we can selectively PERMIT or DENY attribute<br class="">
propagation using an "Attribute Filter Policy,” but that’s not what<br class="">
we’re looking for in this case.<br class="">
</blockquote>
<br class="">
The SP's attribute policy will allow you to say "I only accept<br class="">
attribute X from IDP Y", which seems to be just what you want. If<br class="">
you're saying the policy operates on internal names (which is correct)<br class="">
and therefore you cannot distinuish different attributes because you<br class="">
chose to map different attributes of all kinds into the same internal<br class="">
name in the step before... well, don't do that.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>-> Define attribute X as Y if from IdP A</div>
<div>-> Define attribute X as Z if from IdP B</div>
<div>-> ….and so on</div>
<div><br class="">
</div>
<div>Unfortunately, I do not think this operation is supported.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">Is this at all possible or is it required (or even best-practice) to<br class="">
define each custom attribute with a unique “id” ?<br class="">
</blockquote>
<br class="">
If you first map all attributes into a single internal name you cannot<br class="">
treat them differently in the policy. So if you really wanted to go<br class="">
the way of filtering attributes based on the issuer, you'd have to map<br class="">
them unto different ids in the mapper.<br class="">
Personally I'd map differnt attributes unto different internal names<br class="">
and the semantically same attribute (going by different names) into<br class="">
the same internal name. You're then free to do additional filtering,<br class="">
or not, depending on the uniqueness/chaos of the data you decided to<br class="">
accept.<br class="">
Then either iterate over the list of all possible attributes in your<br class="">
own code once, and re-use everywhere else, or use the SP's<br class="">
functionality to do just that.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>-> use header X as an ID with school A</div>
<div>-> use header Y as an ID with school B</div>
<div>-> ….and so on</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">-peter<br class="">
-- <br class="">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">
users-unsubscribe@shibboleth.net</a></div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>