IEEE Computer Society
Identity Federation in Cancer
Biomedical Informatics Grid (caBIG )
TM
A Federated Identity Management Case Study
Tim Weil – CISSP, CISA
Ken Lin - CISSP
Booz Allen Hamilton
Identity Management Architect
Reston, Virginia
19 April 2006
Tech Day VI
0
Agenda
 The Evolution of the Cancer Research and the Grid Infrastructure
 Grid Security Architecture and Federated Identity Management (FIM)
 FIM Use Cases and Architecture
 Technology Evaluation and Recommendations
 Summary
Tech Day VI
1
Cancer Biomedical Informatics Grid builds the framework for
sharing biomedical research information
 The deciphering of the human genome offers insight into the development of numerous
therapies, predictors, and markers for cancer
 Annotated human biospecimens with detailed clinical information offers an unprecedented
opportunity for the robust identification and accurate quantitation of molecular signatures of
cancer, thereby accelerating the development and implementation of new cancer markers and
therapies
 The lack of common infrastructure has prevented life science research institutions from being
able to mine and analyze disparate data sources
 The inability to share technologies and data developed by different cancer research institutions
can severely hamper the research process
 The NCI Center for Bioinformatics (NCICB) created the project cancer Biomedical Informatics
TM
Grid (caBIG ) and built the caGrid 0.5 prototype to satisfy simple data integration and sharing
use cases
Tech Day VI
2
Grid is a Service Oriented Architecture (SOA) implementation to
enable cross-organizational collaboration
Tech Day VI
3
NCI Mission Statement
Tech Day VI
4
Tech Day VI
5
This effort focuses on the authentication and authorization of the
Identity and Access Management Operating Model
Protect
Intellectual
Property
Protect
Sensitive
Data
Protect
Privacy Data
CAPSTONE
POLICIES
INFORMATION SHARING/PROTECTION
ENABLING
PROCEDURES
AND
MECHANISMS
User
Workstation
Router
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
User
Workstation
User
Workstation
ATM
Switch
Directory
Server
SONET
Mux
PKI CA
User
Workstation
Router
User
Workstation
ATM
Switch
Domain Name
System Server
SONET
Mux
Directory
Server
PKI CA
User
Workstation
Router
Governance
and Oversight
Training and
Awareness
Certification and
Accreditation
Physical
Authorization
Router
Domain Name
System Server
Risk Management
SUPPORTING
Authentication
Storage
Credential
Management
ENABLING
IdAM
STANDARS
AND
GUIDELINES
Entity
Management
CORE IdAM
Verification
BUSINESS
DRIVERS
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
Focused
Standardization
Integration
TECHNICAL & SECURITY ARCHITECTURE
DATA
STANDARDS
Identity
DATA STANDARDS LAYER
Tech Day VI
6
Maturity
Low
Medium
High
Electronic Data
Assurance
Identity and Access Management Operating Model (Authentication & Authorization)
Protect
Privacy
Data
Protect
Intellectual
Property
Protect
Sensitive
Data
INFORMATION SHARING/PROTECTION
BUSINESS DRIVERS
CAPSTONE POLICIES
• Capstone policies provide overall guidance for managing compliance risk within the
enterprise IT information sharing program.
• Derived from multi-jurisdictional regulations and standards including HSPD-12, FIPS
201, eAuthentication, HIPAA, and FDA 21 CFR Part 11,
• These policies reflect measures established through the best practices suggested by
the various regulatory bodies.
Tech Day VI
7
Identity and Access Management Operating Model (Authentication & Authorization)
Enabling IdAM Standards and Guidelines
BUSINESS DRIVERS
At the IT security layer, the IdAM Standards and Guidelines drive interoperability and serve as the
operational baseline for inserting the capstone policies. Typical standard and guideline categories
that apply include: Directory Services (LDAP), Public Key Infrastructure (PKI), Trust Domains
(Federation), and Access Control Models (RBAC and ABAC).
Tech Day VI
8
Governance
and Oversight
Training and
Awareness
Verification
Certification
and
Accreditation
Risk
Management
Physical
Authorization
SUPPORTING
Authentication
Storage
Credential
Management
Entity
Management
CORE IdAM
Identity and Access Management Operating Model (Authentication & Authorization)
BUSINESS DRIVERS
Enabling Procedures and Mechanisms
IdAM Enabling Procedures and Mechanisms are determined by the maturity of the
organization, level of assurance and sensitivity of the data.
•Procedures - Key procedures must be identified to support the enterprise IT IdAM
operating model. The procedures contain levels of maturity ranging from Low to
High consistent with the needs of system information sharing efforts. Enterprise IT
should have flexibility in implementing appropriate levels of maturity consistent with
the complexity of their efforts.
•Mechanisms – The key mechanisms that must be identified to support the
operating model and procedures which contain levels of maturity ranging from Low
to High consistent with the needs of the enterprise IT information sharing efforts.
Tech Day VI
9
Identity and Access Management Operating Model (Authentication & Authorization)
BUSINESS DRIVERS
User
Workstation
Router
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
User
Workstation
Enabling Procedures and Mechanisms
Router
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
User
Workstation
Router
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
User
Workstation
PKI CA
Router
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
Focused
Maturity
Standardization
Integration
TECHNICAL & SECURITY ARCHITECTURE
Low
Medium
Assurance
High
Tech Day VI
10
Identity and Access Management Operating Model (Authentication & Authorization)
BUSINESS DRIVERS
Data Standards for Identity Management
The IdAM Data Standards layer represents Identity and Electronic Data which may be modeled
as business transaction data (SOAP messages), metadata (XML Schemas), or metalanguages
(Data Dictionaries, Logical Data Model). Enterprise IT should leverage the data standards for
identity management such as federated identity standards (i.e. SAML, Shibboleth, WS-*) and
cryptography standards (i.e. PKIX - X.509 )
Identity
DATA STANDARDS LAYER
Electronic Data
Tech Day VI
11
This effort focuses on the authentication and authorization of the Identity and Access
Management Operating Model
Protect
Intellectual
Property
Protect
Sensitive
Data
Protect
Privacy Data
CAPSTONE
POLICIES
INFORMATION SHARING/PROTECTION
ENABLING
PROCEDURES
AND
MECHANISMS
User
Workstation
Router
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
User
Workstation
User
Workstation
ATM
Switch
Directory
Server
SONET
Mux
PKI CA
User
Workstation
Router
User
Workstation
ATM
Switch
Domain Name
System Server
SONET
Mux
Directory
Server
PKI CA
User
Workstation
Router
Governance
and Oversight
Training and
Awareness
Certification and
Accreditation
Physical
Authorization
Router
Domain Name
System Server
Risk Management
SUPPORTING
Authentication
Storage
Credential
Management
ENABLING
IdAM
STANDARS
AND
GUIDELINES
Entity
Management
CORE IdAM
Verification
BUSINESS
DRIVERS
User
Workstation
ATM
Switch
Domain Name
System Server
Directory
Server
SONET
Mux
PKI CA
Focused
Standardization
Integration
TECHNICAL & SECURITY ARCHITECTURE
DATA
STANDARDS
Identity
DATA STANDARDS LAYER
Tech Day VI
12
Maturity
Low
Medium
High
Electronic Data
Assurance
Identity and Access Management – Evolutionary Model
Federated Identity
Enterprise Portal
Integrated
Provisioning
Business Value
Trusted Identity
Maturity
Assessment
IdAM
Requirements
Develop the IdAM
capability
requirements and
assurance levels to
support business
capabilities
Assess the maturity
level of an
organization’s IdAM
capability
Establish an
organizational wide
trusted identity and
identity proofing
process
Provision entity
attributes from
various authoritative
sources to the
trusted identity
Standardization
Focused Capabilities
Cost and Complexity
Tech Day VI
13
Simplified Sign On,
credential based
authentication,
centralized privilege
management
Cross enterprise
information sharing
with trusted identity
and access policies
Integration
caGrid 0.5 Identity and Access Management (IdAM) Architecture
Secure Communication
Single Sign On
User A
User C
Delegation
Username/
Password
Username/
Password
…..
Ohio State
NCI
Proxy Cert
caBIG
Proxy Cert
Proxy Cer
Proxy Cert
Username/
Password
GUMS
GUMS
 GUMS: Grid User
Management Service
User B
Username/
Password
Proxy Cert
Proxy Cert
User D
Tech Day VI
14
Federated Authentication Scenarios
 Non-caGrid Certificate. John Smith wants to use the X.509 certificate obtained from a 3rd
party Certification Authority to access caBIG services
 caGrid-Certificate. John Smith uses caGrid X.509 certificate to access caBIG services
 No Certificate. John Smith wants to use the Email username and password to access
caBIG services
 Implications
– caGrid needs to accept credentials of different assurance levels
– Assurance levels are defined by 1) the identity proofing process, AND 2) the credential itself
– In the identity federation environment, the architecture needs to accommodate existing
credentials rather than creating new credentials
– Credential management will fall on the organization who issues the credential
Tech Day VI
15
Federated Authentication Architecture leveraging the
EAuthentication architecture
Federated Authentication Architecture
Authentication Assertion
NCI
xy
Georgetown
Identity
Federation Service (IFS)
Certification
Authority
Pro
Georgetown
LDAP
Ce
rt
Grid Certificate
Username and password
caBIG
Pr
ox
Authentication
Authority Registry
yC
e
rt
Certification
Authority
Service
UPMC
Fox Chase
Certificate
UPMC Hardware
Token
Identity
Federation Service (IFS)
Tech Day VI
16
Fox Chase
Certification
Authority
Assertion Based Scenario (Users without X.509 certificates)
Assertion Based Authentication
2. Where is Georgetown’s
Authentication Authority?
1. Request Access to caBIG
Georgetown
User
3. URL of Georgetown’s
Authentication Authority
5. Submit Username
and Password
4. Redirect Users to
Georgetown LDAP
Authentication
Authority Registry
8. The IFS generates a X.509
certificate for the user
Identity
Federation Service (IFS)
Pro
7. Georgetown LDAP generates
an authentication assertion
xy
Ce
rt
9. The IFS generates proxy
certificates for the user
Credential Service Provider
(Georgetown LDAP)
caBIG
6. Georgetown LDAP
authenticates the user
Tech Day VI
17
Certificate Based Scenario (Users with X.509 certificates)
Certificate Based Authentication
1. Request Access to caBIG with
a Fox Chase certificate
2. Where is Fox Chase’s
Authentication Authority?
Fox Chase
User
3. URL of Fox Chase’s
Authentication Authority
4. Is this certificate still
valid (Not expired)?
Authentication
Authority Registry
6. The IFS generates a X.509
certificate for the user
Identity
Federation Service (IFS)
Pro
5. Yes, the certificate is valid
Credential Service Provider
(Fox Chase Validation Service)
xy
Ce
rt
7. The IFS generates proxy
certificates for the user
caBIG
Tech Day VI
18
Federated Authorization Scenarios
 Mary Smith owns the Protein Database System (PDBS) at Rutgers University.
–
caBIG Users Access Policy. caBIG users must be Medical Doctors with 10 years of
experience approved to be qualified PDBS users
–
Local Access Policy. caBIG qualified users can only use PDBS from 10:00am to
11:00am EST everyday. Other timeslots are reserved for Rutgers users.
 Joan Taylor owns the Cell Attachment Analytical Service (CAAS) at University of Pittsburgh.
The CAAS is used in the Hope research project with participants from different organizations
in caBIG.
–
Privilege Delegation and Group Membership. Only Hope project manager from caBIG
have read and write privileges to the CAAS. The Hope project manager can delegate
read and write privileges to Hope project members.
–
Provisioning/Auditing. The IRB at University of Pittsburgh needs to know who has read
and write privileges to CAAS on the weekly basis.
Tech Day VI
19
Federated Authorization Architecture using the attribute based
authorization
Federated Authorization Architecture
PEP
Medical Doctor
10 years of Experience
Georgetown
User
Georgetown
Entity Attribute
Authority
Fox Chase
Clinical Trial
Management System
PDP/ADS
PDP/ADS
PDP/ADS
caBIG
Attribute
Authority
Registry
Hope Project
Membership
Hope
Project Owner
10:30 am EST
Fox Chase
Time Server
PEP: Policy Enforcement Point
Hope Project
Member Privileges
PDP: Policy Decision Point
UPMC
Project Attribute
Authority
ADS: Attribute Discovery Service
Tech Day VI
20
An illustrative example of federated identity management
GRID Service
Users
Varying assurance level
credentials
Userid/password
X.509 Certs
Smartcards
Tokens
Authentication
Service
Authorization
Service
Validation
Service
Attribute Discovery
Service
Org.
NCICB
Attribute
Credential
Service
Provider
Credential
Service
Provider
Credential
Userid/password Service
X.509 Certs
Provider
Smartcards
Tokens
Fox
Chase
Virtual Organization
User
Project
…
…
…
…
Tech Day VI
21
The following open source technologies were evaluated based on
the notional architecture
Technology
Version
Purpose
Globus Grid Security Infrastructure (GSI)
4.0.1
Provide service delegation, single-sign-on, and PDP chaining for
grid infrastructure
Shibboleth/GridShib
1.3 /
Beta
 Providing attribute authority services with Web based
authentication
 Pulling authorization attributes from the Shibboleth attribute
authority service to grid services
SAML (OpenSAML)
1.x
Provide authentication, authorization decisions and attribute
assertions
Grid User Management Service
0.5
User account management tool
caGrid Authorization Management
Service
0.5
User attributes management tool
Grouper
0.5.6
Signet
0.5
Enterprise privilege management tool
SAFE
2.0
FDA 21 CFR Part 11 compliance credential
Common Security Module (CSM)
3.0.1
Enterprise group management tool
NCI security library for developers
Tech Day VI
22
Illustrative mapping of authentication technologies
Federated Authentication Architecture
rative
Illust
GridLogon / GUMS
Authentication Assertion
Grid Certificate
NCI
xy
Georgetown
Identity
Federation Service (IFS)
Pro
Georgetown
LDAP
Ce
rt
SAML
Username and password
caBIG
Pr
o
xy
C
Authentication
Authority Registry
Certification
Authority
GSI Proxy
Certificate
ert
Certification
Authority
Service
UPMC
Fox Chase
Certificate
UPMC Hardware
Token
SAFE Credential
Identity
Federation Service (IFS)
GridLogon / GUMS
Tech Day VI
23
Fox Chase
Certification
Authority
Illustrative mapping of authorization technologies
ra
Illust
tive
Grouper/Signet
Federated Authorization Architecture
CSM
CAMS
Medical Doctor
10 years of Experience
Georgetown Georgetown
User
Entity Attribute
Authority
PDP/ADS
Shibboleth
Attribute Authority
Service
PEP
GSI PDP
Chaining
Fox Chase
Clinical Trial
Management System
PDP/ADS
PDP/ADS
caBIG
Attribute
Authority
Registry
Hope Project
Membership
Hope
Project Owner
UPMC
Project Attribute
Authority
10:30 am EST
Fox Chase
Time Server
PEP: Policy Enforcement Point
Hope Project
Member Privileges
PDP: Policy Decision Point
GridShib(SAML)
ADS: Attribute Discovery Service
Tech Day VI
24
The evaluation shows many technologies are still in early
development stages
Technology
Status of Current Release
Globus GSI Proxy Certificate
4.0 is available
Globus GridLogon/MyProxy
Cannot generate end entity certificates (EECs) in our testing release. Importing a
SAFE credential will violate the non-repudiation requirement in the SAFE Standard.
Does not support assertion based authentication method.
Globus GSI PDP Chaining
4.0 is available
Shibboleth Attribute Authority Service
1.3 is available
GridShib
Beta. “Pull” mode is ready at the current release.
SAML
1.1 is available
GUMS
0.5 is available. Already runs as a caBIG service. Does not support assertion
based authentication method. Cannot accept SAFE credentials.
CAMS
0.5 is available. Already runs as a caBIG service. Integrates with caBIG data
standards. Does not support SAML attribute assertion.
Grouper & Signet
0.5.6 Pre-Beta, does not have a grid service interface
CSM
3.0.1 works with LDAP and relational database as the back end. Cannot work with
certificate back end currently.
SAFE
2.0 is available
Tech Day VI
25
Identity and Access Management – Evolutionary Model
Federated Identity
Enterprise Portal
Integrated
Provisioning
Business Value
Trusted Identity
Maturity
Assessment
IdAM
Requirements
Develop the IdAM
capability
requirements and
assurance levels to
support business
capabilities
Assess the maturity
level of an
organization’s IdAM
capability
Establish an
organizational wide
trusted identity and
identity proofing
process
Provision entity
attributes from
various authoritative
sources to the
trusted identity
Standardization
Focused Capabilities
Cost and Complexity
Tech Day VI
26
Simplified Sign On,
credential based
authentication,
centralized privilege
management
Cross enterprise
information sharing
with trusted identity
and access policies
Integration
Identity and Access Management (IdAM Framework)
Credentialing
Authentication
Storage
Assurance Level
Trusted Identity
Identity Proofing
Entity Management
Human Resource
Provisioning
Credential
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Authorization
Attributes
Attribute
Business Events
CRM
Attribute
Business Partner
Attribute
Authoritative Sources
Tech Day VI
27
Architecture and Technology Recommendations
Develop “business-oriented” security use and abuse cases.
caBIG™ should develop “business-oriented” security use cases to represent community processes. The technical focus of the
current security use cases (iteration 2) does not represent the actual security requirements from the caBIG™ community. Since
identity federation relies more on process than technology, this white paper defines a set of federated authentication and
authorization scenarios as a basis to develop the notional architecture. The caBIG™ community should conduct further scenario
definition and refinement to promote a more comprehensive federation architecture.
Vet the Federated Identity Management (FIM) requirements and the notional architecture.
The FIM requirements and the notional architecture are straw man efforts that the caBIG™ community should vet extensively to
validate that all security use cases are satisfied before the production implementation. The proposed notional architecture focuses
solely on authentication and authorization. Other core identity and access management (IdAM) and supporting services will evolve
as the “business-oriented” security use cases are developed.
Proof-of-concept (POC) implementation.
Due to the complexity of the evaluated technologies, a POC implementation of the notional architecture would provide greater
clarity into the accuracy of the security use case development and how the notional architecture best applies. The POC should be
built on top of the caBIG™ 0.5 release, however, many implementation requirements need to be evaluated.
Consider the maturity of technologies.
Very few technologies in the evaluation list have been deployed in a large scale of production environment. Many evaluated
technologies have very limited development resources that would impact the quality and the capability of production support once
the software is released.
Tech Day VI
28
Policy and Regulatory Environment Recommendations
Develop caBIG™ Governance Policies.
A successful security implementation requires policies in many layers. For example, the capstone policies (e.g. HIPAA, 21 CFR
Part 11 compliance, trust agreements), the enabling standards, guidelines, procedures (e.g. Identity proofing), and data standards
(e.g. Authorization Attributes) should be developed along with the IdAM mechanism.
Facilitate Cross-Cutting Policy Development.
A successful security implementation requires policies in many layers. For example, the capstone policies (e.g. HIPAA, 21 CFR
Part 11 compliance, trust agreements), the enabling standards, guidelines, procedures (e.g. Identity proofing), and data standards
(e.g. Authorization Attributes) should be developed along with the IdAM mechanism.
Identify the minimum security requirements from the regulatory mandates.
Security and privacy requirements from regulatory mandates are the minimum security requirements caBIG needs to comply.
Although HIPAA and 21 CFR Part 11 were reviewed in this whitepaper, it’s strictly from the identity federation point of view. A
comprehensive review should be conducted to capture all security and privacy requirements. It is likely those requirements will
impact many workspaces and working groups in caBIG.
Consider separating regulated and non-regulated environments.
Ensure a non-grid application to comply with regulatory requirements takes significant efforts and cost. Mixing regulatory and nonregulatory applications will elevate the required security controls, which is not necessary for many non-regulatory applications.
caBIG should consider the design option of separating the technical architecture layer of regulated and non-regulated
environments and enabling the data sharing at the semantic layer.
Tech Day VI
29
Process and Execution Recommendations
 Create an “Independent and Integrated” cross-cutting security working group.
– Domain workspaces are disconnected from security implementation
– No consolidated (from domain workspaces) security requirements
– Inconsistent security messages from different domain workspaces
– Lack of resource for security architecture to bridge the caBIG™ security principles an
implementation
 Develop a security engineering process.
– The security engineering process (SEP) will specify roles and responsibilities, identify
process steps, and define inputs and deliverables. The security working group (if created)
should use the SEP to ensure security is integrated into domain workspaces, security
architecture is defined and vetted, and implementation is aligned.
Tech Day VI
30
Security Engineering Process


()
Tech Day VI
31
Security Engineering Process (cont)
()


Tech Day VI
32
The real challenges of cross-institutional data sharing is political
and cultural not technical
 The Institutional Review Board (IRB) is the ultimate authority for defining security and privacy
compliance policies. To share sensitive medical information among institutions would require
IRBs’ approval and an individual trust agreement needs to be established (n^2 problem)
 Currently, two data sharing mechanisms among institutions:
– Public data, no access control is required
– Sensitive data, access control is required
The concept of assurance level does not exist in the current practices of healthcare industry
 Healthcare SOA security problems are complex as epitomized by
– Infrastructure Gaps: Some institutions are using Excel sharing data while some are using
biomedical informatics systems
– Scientific vs. Engineering Mindset: Enthusiastic about technologies, needs to understand
the importance of having an integrated engineering process
– Regulatory Compliance: IRBs are very conservative in crafting data sharing policies.
Large scale agreement is difficult
Tech Day VI
33
Thank you for joining us!
For BAH Identity and Access Management Identity Federation
Kenneth Lin
Senior Consultant
Booz | Allen | Hamilton
Tel (703) 377-5662
lin_kenneth@bah.com
Tech Day VI
34
Tech Day VI
35
Example Security Architecture – SAFE
From caBIG™ security whitepaper
Tech Day VI
36