IEEE Computer Society
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Reston, Virginia 19 April 2006 PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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. Agenda.

Download Presentation

Reston, Virginia 19 April 2006

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Reston virginia 19 april 2006

IEEE Computer Society

Identity Federation in Cancer Biomedical Informatics Grid (caBIGTM)

A Federated Identity Management Case Study

Tim Weil – CISSP, CISA

Ken Lin - CISSP

Booz Allen Hamilton

Identity Management Architect

Reston, Virginia

19 April 2006


Agenda

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


Cancer biomedical informatics grid builds the framework for sharing biomedical research information

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 Grid (caBIGTM) and built the caGrid 0.5 prototype to satisfy simple data integration and sharing use cases


Reston virginia 19 april 2006

Grid is a Service Oriented Architecture (SOA) implementation to enable cross-organizational collaboration


Nci mission statement

NCI Mission Statement


Reston virginia 19 april 2006

This effort focuses on the authentication and authorization of the Identity and Access Management Operating Model

Protect Intellectual Property

Protect Privacy Data

Protect Sensitive Data

BUSINESS DRIVERS

INFORMATION SHARING/PROTECTION

CAPSTONE POLICIES

CORE IdAM

SUPPORTING

ENABLING IdAM STANDARS AND GUIDELINES

Credential

Management

Storage

Authentication

Authorization

Risk Management

Certification and

Accreditation

Verification

Training and

Awareness

Governance

and Oversight

Entity

Management

Physical

ENABLING PROCEDURES AND MECHANISMS

Focused

Standardization

Maturity

Integration

TECHNICAL & SECURITY ARCHITECTURE

Assurance

Low

Medium

High

DATA STANDARDS

DATA STANDARDS LAYER

Identity

Electronic Data


Identity and access management operating model authentication authorization

Protect Intellectual Property

Protect Privacy Data

Protect Sensitive Data

INFORMATION SHARING/PROTECTION

CAPSTONE POLICIES

BUSINESS DRIVERS

  • 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.

Identity and Access Management Operating Model (Authentication & Authorization)


Identity and access management operating model authentication authorization1

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).

CORE IdAM

SUPPORTING

Certification

and

Accreditation

Risk

Management

Storage

Authentication

Authorization

Verification

Training and

Awareness

Entity

Management

Credential

Management

Governance

and Oversight

Physical

Identity and Access Management Operating Model (Authentication & Authorization)


Identity and access management operating model authentication authorization2

Enabling Procedures and Mechanisms

BUSINESS DRIVERS

Identity and Access Management Operating Model (Authentication & Authorization)

  • 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.


Identity and access management operating model authentication authorization3

Enabling Procedures and Mechanisms

BUSINESS DRIVERS

TECHNICAL & SECURITY ARCHITECTURE

Low

Assurance

Medium

Focused

Maturity

Standardization

High

Integration

Identity and Access Management Operating Model (Authentication & Authorization)


Identity and access management operating model authentication authorization4

  • Data Standards for Identity Management

BUSINESS DRIVERS

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

Identity and Access Management Operating Model (Authentication & Authorization)


Reston virginia 19 april 2006

This effort focuses on the authentication and authorization of the Identity and Access Management Operating Model

Protect Privacy Data

Protect Intellectual Property

Protect Sensitive Data

BUSINESS DRIVERS

INFORMATION SHARING/PROTECTION

CAPSTONE POLICIES

CORE IdAM

SUPPORTING

ENABLING IdAM STANDARS AND GUIDELINES

Credential

Management

Authentication

Authorization

Risk Management

Certification and

Accreditation

Verification

Training and

Awareness

Governance

and Oversight

Storage

Entity

Management

Physical

ENABLING PROCEDURES AND MECHANISMS

Focused

Standardization

Maturity

Integration

TECHNICAL & SECURITY ARCHITECTURE

Assurance

Low

Medium

High

DATA STANDARDS

DATA STANDARDS LAYER

Identity

Electronic Data


Identity and access management evolutionary model

Identity and Access Management – Evolutionary Model


Cagrid 0 5 identity and access management idam architecture

caGrid 0.5 Identity and Access Management (IdAM) Architecture

  • GUMS: Grid User Management Service


Federated authentication scenarios

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


Federated authentication architecture leveraging the eauthentication architecture

Federated Authentication Architecture leveraging the EAuthentication architecture


Assertion based scenario users without x 509 certificates

Assertion Based Scenario (Users without X.509 certificates)


Certificate based scenario users with x 509 certificates

Certificate Based Scenario (Users with X.509 certificates)


Federated authorization scenarios

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.


Federated authorization architecture using the attribute based authorization

Federated Authorization Architecture using the attribute based authorization


An illustrative example of federated identity management

Varying assurance level credentials

Users

Userid/password

X.509 Certs

Smartcards

Tokens

Org.

NCICB

Fox Chase

Attribute

User

Virtual Organization

Userid/password

X.509 Certs

Smartcards

Tokens

Project

Credential

Service

Provider

Credential

Service

Provider

Credential

Service

Provider

An illustrative example of federated identity management

GRID Service

Authentication

Service

Authorization

Service

Validation

Service

Attribute Discovery

Service


The following open source technologies were evaluated based on the notional architecture

The following open source technologies were evaluated based on the notional architecture


Illustrative mapping of authentication technologies

Illustrative mapping of authentication technologies


Illustrative mapping of authorization technologies

Illustrative mapping of authorization technologies


The evaluation shows many technologies are still in early development stages

The evaluation shows many technologies are still in early development stages


Identity and access management evolutionary model1

Identity and Access Management – Evolutionary Model


Identity and access management idam framework

Identity and Access Management (IdAM Framework)


Architecture and technology recommendations

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.


Policy and regulatory environment recommendations

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 non-regulatory 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.


Process and execution recommendations

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.


Security engineering process

Security Engineering Process

()


Security engineering process cont

Security Engineering Process (cont)

()


The real challenges of cross institutional data sharing is political and cultural not technical

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


Thank you for joining us

Kenneth Lin

Senior Consultant

Booz | Allen | Hamilton

Tel (703) 377-5662

[email protected]

Thank you for joining us!

For BAH Identity and Access Management Identity Federation


Example security architecture safe

Example Security Architecture – SAFE

From caBIG™ security whitepaper


  • Login