Multiple copies of an attribute?

Mike Flynn shibbolethlynda at yahoo.com
Wed May 29 13:02:36 EDT 2013


They want to send us multiple copies of the ROLE attribute, each with a different value.  The issue for us is that we assume and IDP will send a set of attributes and each has a unique name.  We load these into a dictionary with the attribute name as the key.  If we get 2 copies of role (for example), it would throw an exception from the duplicate key (i.e. two attributes with the same name like ROLE as they indicate).


________________________________
 From: Ian Young <ian at iay.org.uk>
To: Shib Users <users at shibboleth.net> 
Sent: Wednesday, May 29, 2013 9:57 AM
Subject: Re: Multiple copies of an attribute?
 




On 29 May 2013, at 17:25, Mike Flynn <shibbolethlynda at yahoo.com> wrote:

Is it possible for an Idp to send multiple copies of the same attribute?  I have a customer saying they want to send the same attribute multiple times to us with different values.

Although many attributes are defined to be single-valued, many others are defined to be multi-valued, which is what I think you're talking about here.

So, for example, eduPersonScopedAffliation is a multi-vallued attribute.  Saying that someone is both a "member at example.edu" and also a "student at example.edu" is achieved by sending multiple values to your SP.  The SP normally presents these to the application separated by ";"s, so:

member at example.edu;student at example.edu

I have told them we do not support doing that but I was curious if this is an accepted practice or common for an Idp to do this.

Whether an IdP *should* be sending multiple values to you depends partly on the definition of the attribute but mainly on your business relationship and their risk profile. For example, although a single subject might have multiple affiliation values associated with them, an IdP would often choose only to release to an SP those specific values required by the SP.

 We could support this with code updates to manage it but I wanted to see if this is a legit or even common practice.

It's hard to give a definitive answer without details about which attributes and which value we're talking about.  But just as guidance, if we're talking about something where the SP is matching values for authorization purposes (e.g., scoped affiliation or entitlements) you're going to be more flexible if you allow for the possibility that uninteresting values may accompany the ones you care about (Postel's law: be conservative in what you do, be liberal in what you accept from others).

-- Ian




--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130529/3c3d0b6b/attachment-0001.html 


More information about the users mailing list