InCommon Library Services

[Tod Olson <>]

On Apr 5, 2007, at Apr 5, 3:45 PM,  wrote:

> I'd like to suggest two action items:
>
> 1) could each campus post to the (new!) email list the set of the  
> issues they feel they'll need to address in order to begin to use  
> Shibboleth within their library services. Possible issues might be  
> technical, integration, user experience, process, policy,  
> whatever.....

This is the University of Chicago reply. There are few obstacles to  
our using Shibboleth at this point. We have some technical issues  
that are actually preventing us from moving forward, then we have  
some policy/process issues that would not prevent offering Shibboleth  
on campus, but would have to be dealt with eventually.

I. Technical challenges to offering Shibboleth-mediated authorization  
on campus:

-- We need to be able to continue our current level of functionality  
under a load-balancing environment.

-- We need to figure out how to use one (1) IdP for multiple trust  
relationships, or to manage IdP instances for different trust  
relationships. One of the issues is that not all trust partners seem  
to trust the same Certificate Authorities. That means different SPs  
may need to see different certs, which in turn means having different  
instances of the IdP so we can present different certs. Unless some  
trust partners change their policies. E.g. InCommon seems to only  
recognize the InCommon CA, but InCommon is not our only trust  
relationship, and we cannot expect the other trust partners to accept  
the InCommon CA.

-- Need to set up our own SPs to get more comfortable with the whole  
of the authorization environment, and to figure out how to protect  
our own resources with Shib.

II. Policy/process issues (would not prevent the first couple SPs,  
but will need to be dealt with):

-- There needs to be a process or responsible party to determine the  
attribute release policy for each SP, which may require decision  
making and review. This is more of an issue, for example, if the SP  
wants an actual individual identifier for a person, rather than just  
an affiliation attribute. The more privacy we erode, the more of an  
issue we have.

-- For some SPs, we want different access for walk-up patrons vs.  
remote patrons. That is, while patrons who are not physically present  
must present authentication credentials, we want patrons in the  
library or on campus to be authorized because of their physical  
location.

-- At least one service we want to use Shibboleth with do not yet  
formally support it, but has informal support and can not yet receive  
attributes.

-- There are some special cases where authorization relies on  
information not contained in the campus IdP. For example, alumni who  
have paid for borrowing privileges are eligible to use Interlibrary  
Loan, but the campus IdP does not have this information (nor should  
it); students working as research assistants often act as proxies for  
faculty, and so have two roles which must be kept distinct. (We plan  
to work with the campus IdP for most cases, and deal with special  
cases through some other mechanism.)


Tod Olson <>
Systems Librarian
University of Chicago Library