Shibboleth Developers

At 4:50 PM +0100 4/30/04, Simon McLeish wrote:
> We would like to ask a few questions about how Shib targets 
> (principally commercial targets, though other responses are welcome) 
> are planning to use the role based authorisation made possible by 
> software such as Shibboleth.  If possible, answers by the end of 
> next week (7 May 2004).

I'm not sure how many of the vendors are on these lists; we often 
communicate with them directly. We could also  use the Shib  ACA-SIG 
forum....

Based on our conversations with a number of these vendors, tho, let 
me try to provide some feedback.

-- most of the contracts that we've encountered  so far have been of 
the "students, faculty, staff,and library walkins are authorized to 
use the licensed resource" variety. In these situations, the two 
parties  will be using a Federation-defined entitlement value to 
describe whether a specific browser user is authorized.

-- many/most of the vendors  have been keenly interested in the 
targetedId attribute. This would allow them to personalize their 
service for each user, while allowing the user to remain  anonymous.

-- some of the vendors (especially those  targeting the medical 
community) have started thinking about how to use an attribute that 
would  represent "this person is associated with the Medical School"; 
so far, we've talked  about trying to leverage the OU attribute for 
this purpose.

-- I don't remember  any specific discussions about using ROLEs. We 
have occasionally discussed "possibilities afforded by using  ROLEs" 
with some vendors; however, I don't currently know of any specific 
efforts or projects in this area.

> When role based authorisation becomes possible via Shibboleth do you 
> plan to make use of it?

Shibboleth transports attributes. Those attributes can represent 
*anything* that the two parties agree to, including ROLEs. So, in 
that sense, Shibboleth today supports  role-based authorization.

My sense would be that situations that could take advantage of 
attributes specifying ROLEs are probably web-based applications of 
some sort, and that these applications already include some sort of 
access control  mechanism (ie something that can answer the question 
'can this person do X with resource Y?"). If those applications are 
structured to use ROLEs, that Shibboleth can provide the ROLE values.

> If so, then beyond identifying 'membership' (however that is 
> defined) of an institution licensed to access your online resources, 
> if an institution wished to license access on a more restrictive 
> basis, what types of role or status factors would you expect to use 
> (or, would you expect institutions to wish to use) to distinguish 
> individuals covered by the license, from individuals with no access?

as noted above, the "more restrictive basis" situations that we've 
encountered so far include:

-- associated with a school  or department (typically medicine, law, 
or business)

-- associated with a particular course (CS 101 @ brown  univ)

-- associated with a particular VO

-- individually authorized at the home campus (eg searching database 
X at vendor Y is billed on a "per search" basis; a reference 
librarian at campus Y must  individually grant Jane Doe the authority 
to search this db).

-- and probably some others that I've forgotten......

we think there's a lot of potential here.... however, everyone has to 
move along a learning curve....

> Secondly, what functionality will you be implementing based on roles 
> (restrict access to parts of databases; different "skins" for 
> different types of user; better focused resource discovery; 
> storing/tracking of searches etc.; other)? What user attributes 
> would you wish to use to do this - please be as specific as 
> possible, but at least indicate which of the following broad 
> categories you would be looking for: subject areas of interest (e.g. 
> derived from organisational unit); type of user (e.g. 
> status/affiliation); other...

I think several of  these items  (eg different skins, better focused 
resource discovery, storing/tracking of searches) can be done by 
using targetedId, and don't need ROLEs..... the target doesn't need 
to  know WHO I am in  order to  allow me to personalize how their 
site  looks to me.... they just need to  know  that its  always me 
(-: