Federated Authentication and Authorization to support information sharing: Shibboleth in Project Sen

1
Federated Authentication and Authorization to
support information sharing Shibboleth in
Project Sentinel

• An Update to the
• National Library of Medicine
• June 9, 2005
• Charles F. Leonhardt
• Principal Technologist
• University Information Services
• Georgetown University
• leonhardt_at_georgetown.edu

2
Shibboleth What and Why?

• What is it?
• Internet2 sponsored
• A mechanism to securely transmit, and control the
  release of
• Information relating to a users authenticated
  state without the release of the users ID and
  password to another site
• Attributes about that person (e.g. department,
  name, affiliation)
• Why did we select it for use in Project Sentinel?
• Only standards-based, open-sourced, approach for
  inter-institutional identity information passing
• Relatively easy to support and secure
• Wide adoption in the educational and digital
  content realms

3
Shibboleth The Problem Space

• Inter-institutional Collaboration
• Local Identity Provision and Credentials
• Information Sharing Among Collaborators drives
  the need for local access to distributed
  resources
• Shibboleth allows collaborators to use one
  partners information resources with their local
  credentials with appropriate authentication,
  authorization, and security
• Importance highlighted by increasingly common
  identity theft and compromised information

4
Shibboleth Sentinel Federation
WHC GUH
GUMC - ISIS
DC - DOH
IDs
IDs
IDs
MD
BD
Monitor Man
Azyxxi
IRV
NDVI
Argus
Common Shib Env.
5
Shibboleth Progress to Date

• Shibboleth Enable
• Monitor Man (Done)
• Biosurveillance Applications Environment (Done)
• Azyxxi (In Progress)
• Create Identity Providers for Participants
  (Partially Complete)
• Create Medical Data Profile for ID Attributes (In
  Progress)
• Create Shibboleth communications profile for
  non-browser-based applications (Not Begun)

6
Shibboleth Challenges

• Operational
• Anonymous authentication is not always preferred
  in the medical community
• Explicit Audit/Log data is required
• Infrastructure
• Medical Institutions have immature identity
  infrastructure
• Incomplete or lack of central ID systems MOST
  systems maintain their own user lists and
  passwords
• Small IT staffs already managing as much as they
  can
• Culture
• Medical community has less trust of home
  organizations attributes and want more control of
  privilege granting
• How do they know attributes are assigned
  properly?
• Technical
• Shibboleth does not currently support a clean
  logout process (i.e. destroying of credentials)

7
Shibboleth Next Steps

• Shibboleth-enable first client/server application
  ever Azyxxi
• Protect Identity Providers with multi-factor
  Authentication (Biometrics)
• Create a Sentinel Federation with appropriate
  policies and practices using InCommon Model
• Upgrade to Shibboleth 1.3
• Provide tools to providers to grant privileges to
  remote users
• Use Shibboleth / Signet / Group tool chain
• Investigate Shibboleth / PERMIS tool chain
• Expand Shibboleth into the Grid Space

8
Shibboleth Grid Access

• Shibboleth-Enabled Database Access
• User is authorized through their home institution
  via a Shibboleth enabled web application
• Once authorized, the user is granted access to a
  collection of resources based upon his/her role
  in the organization.
• Resources can each speak with the user via the
  Shibboleth enabled application.
• Queries across resources are a challenge.

9
Globus OGSA-DAI

• Globus and OGSA-DAI enabled database access
• Globus is the reference implementation of the
  OGSA that provides grid tools to build
  applications
• Authentication.
• File transport
• Service discovery
• OGSA-DAI provides connections to database
  resources that allow queries across multiple and
  disparate resources.
• With Globus, users must be manually added to grid
  map files to access resources, making user
  administration a challenge.

Single Certificate Based
10
Middleware is a 2-Tier problem

• For these reasons, it seems clear that the
  middleware challenge is actually a two part
  problem, requiring a two-part stack.
• The upper layer (Shibboleth) handles the users
• The lower layer (Globus) handles the resources

11
Shibboleth and Globus Stage 1

• For now, we envision a Shibboleth enables web
  application that speaks to a Globus/OGSA-DAI
  database application.
• Upper layer authenticates user and verifies
  user's role
• A single Globus proxy is created based upon role
• Lower layer exposes services to authenticated
  users

Single Certificate Based
12
Grid-Shib

• Work is already in progress to create
  Grid-Shib, which would replace the tie between
  the Shibboleth layer and the Globus layer
• Grid-Shib layer would lie between Shibboleth and
  Globus, allowing users who are authenticated
  through the Shibboleth application to seamlessly
  access resources connected via the Globus
  application.

GRIDSHIB
13
Shibboleth Expected Challenges

• Technical Issues
• Azyxxi is written in .Net and there are currently
  no Shibboleth libraries written in .Net
• Special, non-HTTP adapters, will need to be
  created for Shib, the infrastructure to do this
  is new in Shibboleth 1.3 and is, as yet, untested
• The biometric iris-scanners used for protecting
  Azyxxi do not have modules for web servers, which
  would be required for integration with Shib they
  do have client libraries which such modules could
  be created from however
• Tools for managing user accounts in a virtual
  organization are immature at this point and will
  need to be developed
• Policy Issues
• Federations are currently loosely defined and
  allow participants a large amount of room to
  maneuver. A medical federation needs to tighter
  controls and audit capabilities. It is unclear
  if the current federation model will be
  sufficient.

14
Shibboleth Application Demo
GUH WHC
GUMC - ISIS
IDs
IDs
Common Shib Env.
Monitor Man
Azyxxi
IRV
NDVI
Argus
MD
BD
Sentinel Federation (hosted at GU)
1. Local physician at Medstar GUH/WHC wishes to
access IRV application at GUMC-ISIS
2. Physician goes to IRV application
4. Physician authenticates at his home
organization
5. Physician sent back to IRV with proof of
authentication and identity attributes
6. IRV checks attributes and allows physician in
3. Shibboleth sends the physician to
federation to identify his home organization,
which he selects
15
Shibboleth Application Demo
DC - DOH
GUMC - ISIS
IDs
IDs
Common Shib Env.
IRV
NDVI
Argus
MD
BD
Sentinel Federation (hosted at GU)
1. Regional Health Analyst at DC-DOH wishes to
access IRV application at GUMC-ISIS
2. Analyst goes to IRV application
4. Analyst authenticates at his home organization
5. Analyst sent back to IRV with proof of
authentication and identity attributes
6. IRV checks attributes and allows analyst in
3. Shibboleth sends the analyst to federation to
identify his home organization, which he selects
16
Shibboleth Application Demo
DC - DOH
GUMC - ISIS
IDs
IDs
Common Shib Env.
IRV
NDVI
Argus
MD
BD
Sentinel Federation (hosted at GU)
1. Regional Health Analyst at DC-DOH wishes to
access MD application at GUMC-ISIS
2. Analyst goes to MD application
5. MD checks attributes and allows analyst in
4. Analyst sent back with proof of authentication
and attributes (Single Sign-on)
3. Shibboleth sends the analyst to federation
17
Shibboleth Application Demo
DC - DOH
GUMC - ISIS
IDs
IDs
Common Shib Env.
IRV
NDVI
Argus
MD
BD
Sentinel Federation (hosted at GU)
1. Regional Health Analyst at DC-DOH wishes to
access BD application at GUMC-ISIS
2. Analyst goes to BD application
5. BD checks attributes and allows analyst in
3. Shibboleth sends the analyst to federation
4. Analyst sent back with proof of authentication
and attributes (Single Sign-on)
18
Shibboleth Application Demo
DC - DOH
GUMC - ISIS
IDs
IDs
Common Shib Env.
IRV
NDVI
Argus
MD
BD
Sentinel Federation (hosted at GU)
1. Regional Health Analyst at DC-DOH wishes to
access NDVI application at GUMC-ISIS
2. Analyst goes to NDVI application
5. NDVI checks attributes and allows analyst in
3. Shibboleth sends the analyst to federation
4. Analyst sent back with proof of authentication
and attributes (Single Sign-on)
19
Shibboleth Application Demo
GUMC - ISIS
IDs
Common Shib Env.
IRV
NDVI
Argus
MD
BD
1. National DHS analyst working at ISIS wishes to
access Argus application at GUMC-ISIS
2. Analyst goes to Argus application
4. Analyst authenticates at her home organization
5. Analyst sent back to Argus with proof of
authentication and identity attributes
6. Argus checks attributes and allows analyst in
3. Shibboleth sends the analyst to federation to
identify her home organization, which she selects