Presentation on theme: "Agenda The Evolution of the Cancer Research and the Grid Infrastructure Grid Security Architecture and Federated Identity Management (FIM) FIM Use Cases."— Presentation transcript:
0Identity Federation in Cancer Biomedical Informatics Grid (caBIGTM) IEEE Computer SocietyIdentity Federation in Cancer Biomedical Informatics Grid (caBIGTM)A Federated Identity Management Case StudyTim Weil – CISSP, CISAKen Lin - CISSPBooz Allen HamiltonIdentity Management ArchitectBooz Allen Hamilton Standard ColorsColors should be used in the color pairs whenever possible. Do not mix and match colors, use pairs together as shown.Black, White and Gray can be used with any of the other colors.Reston, Virginia19 April 2006Purple Pantone 2765R 12G 4B 79Green Pantone 357R 15G 67B 24Blue Pantone 2 88R 11G 31B 101Pantone Cool Gray 6R 158G 158B 158BlackRed Pantone 485R 252G 5B 14Yellow Pantone 3965R 232G 244B 4Aqua Pantone 319R 126G 204B 189White
1AgendaThe Evolution of the Cancer Research and the Grid InfrastructureGrid Security Architecture and Federated Identity Management (FIM)FIM Use Cases and ArchitectureTechnology Evaluation and RecommendationsSummaryExplain the today’s agenda and the logical flow of the presentation
2Cancer 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 cancerAnnotated 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 therapiesThe lack of common infrastructure has prevented life science research institutions from being able to mine and analyze disparate data sourcesThe inability to share technologies and data developed by different cancer research institutions can severely hamper the research processThe 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 casesExplain what caBIG isExplain why sharing biomedical research information is important to cancer research (the completion of human genome make it possible to associate human genome with cancers)caBIG and caGRID was built to enable sharing biomedical research information
3Grid is a Service Oriented Architecture (SOA) implementation to enable cross-organizational collaborationExplain “Grid”Link the Grid with SOA, Web Services, to enable Virtual OrganizationThe goal: cross-organizational collaboration (VO)Open the question: so how is Grid different from Web Services? (next slide)
6This effort focuses on the authentication and authorization of the Identity and Access Management Operating ModelProtect Intellectual PropertyProtect Privacy DataProtect Sensitive DataBUSINESS DRIVERSCAPSTONE POLICIESINFORMATION SHARING/PROTECTIONCORE IdAMSUPPORTINGENABLING IdAM STANDARS AND GUIDELINESManagementEntityCredentialManagementStorageAuthenticationAuthorizationPhysicalRisk ManagementCertification andAccreditationVerificationTraining andAwarenessGovernanceand OversightENABLING PROCEDURES AND MECHANISMSFocusedStandardizationMaturityIntegrationTECHNICAL & SECURITY ARCHITECTURELowAssuranceMediumDATA STANDARDSHighDATA STANDARDS LAYERIdentityElectronic Data
7INFORMATION SHARING/PROTECTION CAPSTONE POLICIES Identity and Access Management Operating Model (Authentication & Authorization)Protect Privacy DataProtect Intellectual PropertyProtect Sensitive DataINFORMATION SHARING/PROTECTIONBUSINESS DRIVERSCAPSTONE POLICIESCapstone 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.
8Enabling IdAM Standards and Guidelines Identity and Access Management Operating Model (Authentication & Authorization)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).Enabling IdAM Standards and GuidelinesBUSINESS DRIVERSPhysicalManagementEntityCredentialStorageAuthenticationAuthorizationRiskCertificationAccreditationandVerificationTraining andAwarenessGovernanceand OversightCORE IdAMSUPPORTING
9Enabling Procedures and Mechanisms Identity and Access Management Operating Model (Authentication & Authorization)Enabling Procedures and MechanismsBUSINESS DRIVERSIdAM 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.
10TECHNICAL & SECURITY ARCHITECTURE Identity and Access Management Operating Model (Authentication & Authorization)Enabling Procedures and MechanismsBUSINESS DRIVERSFocusedStandardizationIntegrationMaturityTECHNICAL & SECURITY ARCHITECTUREMediumLowHighAssurance
11Identity DATA STANDARDS LAYER Electronic Data Identity and Access Management Operating Model (Authentication & Authorization)Data Standards for Identity ManagementBUSINESS DRIVERSThe 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
12This effort focuses on the authentication and authorization of the Identity and Access Management Operating ModelProtect Intellectual PropertyProtect Privacy DataProtect Sensitive DataBUSINESS DRIVERSCAPSTONE POLICIESINFORMATION SHARING/PROTECTIONCORE IdAMSUPPORTINGENABLING IdAM STANDARS AND GUIDELINESManagementEntityCredentialManagementStorageAuthenticationAuthorizationPhysicalRisk ManagementCertification andAccreditationVerificationTraining andAwarenessGovernanceand OversightENABLING PROCEDURES AND MECHANISMSFocusedStandardizationMaturityIntegrationTECHNICAL & SECURITY ARCHITECTURELowAssuranceMediumDATA STANDARDSHighDATA STANDARDS LAYERIdentityElectronic Data
13Identity and Access Management – Evolutionary Model
14caGrid 0.5 Identity and Access Management (IdAM) Architecture GUMS: Grid User Management Service
15Federated Authentication Scenarios Non-caGrid Certificate. John Smith wants to use the X.509 certificate obtained from a 3rd party Certification Authority to access caBIG servicescaGrid-Certificate. John Smith uses caGrid X.509 certificate to access caBIG servicesNo Certificate. John Smith wants to use the username and password to access caBIG servicesImplicationscaGrid needs to accept credentials of different assurance levelsAssurance levels are defined by 1) the identity proofing process, AND 2) the credential itselfIn the identity federation environment, the architecture needs to accommodate existing credentials rather than creating new credentialsCredential management will fall on the organization who issues the credential
16Federated Authentication Architecture leveraging the EAuthentication architecture
17Assertion Based Scenario (Users without X.509 certificates)
18Certificate Based Scenario (Users with X.509 certificates)
19Federated 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 usersLocal 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.
20Federated Authorization Architecture using the attribute based authorization
21An illustrative example of federated identity management UsersGRID ServiceVarying assurance level credentialsUserid/passwordX.509 CertsSmartcardsTokensAuthenticationServiceAuthorizationServiceValidationServiceAttribute DiscoveryServiceCredentialServiceProviderUserid/passwordX.509 CertsSmartcardsTokens…NCICBFox ChaseUserProjectAttributeOrg.Key Messages:Varying assurance level credentialsMultiple certified credential service providers inside the Grid providing the validation serviceEach participating organization will manage the attributes which they are authoritative forThe red rectangle is an example of Virtual Organization where people from NCICB and Fox Chase are working on the project that Fox Chase administersVirtual Organization
22The following open source technologies were evaluated based on the notional architecture TechnologyVersionPurposeGlobus Grid Security Infrastructure (GSI)4.0.1Provide service delegation, single-sign-on, and PDP chaining for grid infrastructureShibboleth/GridShib1.3 /BetaProviding attribute authority services with Web based authenticationPulling authorization attributes from the Shibboleth attribute authority service to grid servicesSAML (OpenSAML)1.xProvide authentication, authorization decisions and attributeassertionsGrid User Management Service0.5User account management toolcaGrid Authorization Management ServiceUser attributes management toolGrouper0.5.6Enterprise group management toolSignetEnterprise privilege management toolSAFE 2.0FDA 21 CFR Part 11 compliance credentialCommon Security Module (CSM)3.0.1NCI security library for developers
23Illustrative mapping of authentication technologies
24Illustrative mapping of authorization technologies
25The evaluation shows many technologies are still in early development stages TechnologyStatus of Current ReleaseGlobus GSI Proxy Certificate4.0 is availableGlobus GridLogon/MyProxyCannot 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 ChainingShibboleth Attribute Authority Service1.3 is availableGridShibBeta. “Pull” mode is ready at the current release.SAML1.1 is availableGUMS0.5 is available. Already runs as a caBIG service. Does not support assertion based authentication method. Cannot accept SAFE credentials.CAMS0.5 is available. Already runs as a caBIG service. Integrates with caBIG data standards. Does not support SAML attribute assertion.Grouper & Signet0.5.6 Pre-Beta, does not have a grid service interfaceCSM3.0.1 works with LDAP and relational database as the back end. Cannot work with certificate back end currently.SAFE2.0 is available
26Identity and Access Management – Evolutionary Model
28Architecture 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.
29Policy 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.
30Process and Execution Recommendations Create an “Independent and Integrated” cross-cutting security working group.Domain workspaces are disconnected from security implementationNo consolidated (from domain workspaces) security requirementsInconsistent security messages from different domain workspacesLack of resource for security architecture to bridge the caBIG™ security principles an implementationDevelop 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.
33The 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 requiredSensitive data, access control is requiredThe concept of assurance level does not exist in the current practices of healthcare industryHealthcare SOA security problems are complex as epitomized byInfrastructure Gaps: Some institutions are using Excel sharing data while some are using biomedical informatics systemsScientific vs. Engineering Mindset: Enthusiastic about technologies, needs to understand the importance of having an integrated engineering processRegulatory Compliance: IRBs are very conservative in crafting data sharing policies. Large scale agreement is difficult
34Thank you for joining us! For BAH Identity and Access Management Identity FederationKenneth LinSenior ConsultantBooz | Allen | HamiltonTel (703)