1. David Millman—Columbia January 2005
Access Management
David Millman—Columbia
January 2005

2. process between LSE and Columbia so far
planning for scalability – federation-based identity management

3. The Current Pilot designate host to serve shibbolized content
obtain x.509 certificate for host (commercial)
install web server with shibboleth Service Provider (SP) library (apache, IIS)
create pilot federation (“edu-fed.org”)
register DNS
obtain certificates (self-signed)
install shibboleth Identity Provider (IdP), connected to local authentication system and directory (tomcat servlet)

4. The Current Pilot (cont.)
configure IdP to release only the eduPersonScopedAffiliation attribute, e.g.,
configure SP
placement of content within server
set access restrictions (require ...ScopedAffiliation)
both institutions exchange certificates
build “where are you from” service, just for the two institutions

5. demo

7. Scaling—Federations
Bi-lateral doesn’t take advantage of the built-in scalability of the shibboleth architecture
Federation
represents agreement on procedures—legal framework
encourages standards for directory information (eduPerson, course membership)
issues certificates to participants—gateway function
Examples
edu-fed.org (LSE/CU)
inQueue (Internet2 test federation)
inCommon (Internet2 production federation)

8. Federation Implications
may clarify internal agreements about identity management & policy at local institution
information offered to the federation is the same for all members—is that acceptable, without trusting each new member bilaterally?
international questions