Identity Federation & Federated Trust: An Overview. March 11, 2010

Transcription

1 Federation & Federated Trust: An Overview March 11, 2010

2 Introduction to Federated Federated is simply the sharing of user identity information between organizations EMR access will be enabled through federated identity Federation Operator Federated Organization Federated Organization Federated Organization User Information 2

3 Why Federated? Reduces the cost, complexity, and annoyance of provisioning net new user identities to provincial user base Provides the ability to integrate services directly into existing clinical domains Provides a common framework for organizations to share services 3

4 ehealth Federation - Structure The ehealth Federation was constructed to support point to point interaction Federation Operator POS POS 4

5 Federation Scenarios An organization can choose the following approaches to provide its users access to ehealth services Federate directly with ehealth through the organization s /POS and IdP solution. Eg. Hospital ehealth Ontario Org /POS Org IdP Federate indirectly with ehealth by connecting your IdP solution through a partner /POS. Eg. Hospital to LHIN Based ehealth Ontario Partner /POS Partner IdP Org IdP Do not federate. Leverage an existing partner IdP solution and. Eg. ehealth Ontario ehealth Ontario Partner Partner IdP 5

6 ehealth Federated Services Model Data Repositories ehealth Services, Access, and Privacy Control Federation Partners (Delivery Channel) Users OLIS ODB CRR PRR DR Repository DI/PACS 1,2,3,4 CD Repository PA Repository OLIS Viewer ODB Claims History Viewer Client Registry Services Registry Services Diabetes Services DI/PACS Common Services Consent Directive Services Privacy Audit Services Assertion Validation Binding Service Entitlement Consent Directive Filtering Recording of Access Hospitals Large Clinics CCAC s Community Based IdP ONEID Client IdP Hospital LHIN/ Network Community Based ehealth Ontario POS Application Client Affiliated User Unaffiliated User POS User Client User 6

7 ehealth Federation - Responsibilities Federation Operator (Relying Party) Federation Partners (Asserting Parties) ehealth Ontario s Other POS s s Assertion Validation Binding Service Entitlement User Registration Credentials Management User Authentication Delegation Management Assertion 7

8 Joining the Federation 1. Identify interest in Federation Participation Define federation role (POS or IdP) Conduct pre-qualification 3. Address Assurance Gaps Modify internal processes Implement additional controls/technology Perform required PIA/TRA s 5. Execute Federation Agreement Share and review legal agreement Formal acceptance of federation terms 7. Ongoing Verification & Adjustment Periodic assurance audits Requested re-evaluation Collaboration amendments Days to Weeks Weeks to Months Days to Weeks Days to Weeks Days Continuous 2. Evaluate Organization Evaluate against Federation Evaluation Criteria Assess current state Identify gaps based on service delivery objectives 4. Evaluate Gaps for Closure Evaluate gap remediation against Federation Evaluation Criteria Repeat if necessary Identify Collaborations Verify acceptance of PIA/TRA s Formalize evaluation summary as assurance baseline 6. Technically Onramp Organization Populate evaluation summary in the Technical Trust Model Begin accepting assertions from organization 8

9 Evaluating Federation Assurance Organization policies, processes, and technologies will be evaluated and recorded by ehealth Ontario as part of the federation accreditation Organizational Grading Organizational policies, process, and technology User Registration Credentials Management User Authentication Delegation Management Assertion Measured against the Federation Evaluation Criteria AL0 AL1 AL2 AL3 AL4 9

10 Classifying ehealth Services ehealth services will be classified by ehealth Ontario and the Data Custodian according to service and information sensitivity Service Classification Service Sensitivity Risk to Patient Safety Access to PI, PHI Information Classification Financial Liability Risk to Agency Reputation or Public Interest Measured against the Service Impact Assessment Criteria AL0 AL1 AL2 AL3 AL4 10

11 Assertion Validation - Managing Federated Trust View Drugs Service Classification AL0 AL1 AL2 AL3 AL4 Assertion Validation The assurance level (AL) of the organization requesting the service must be equivalent or higher than the service classification Organizational Grading AL0 AL1 AL2 AL3 AL4 11

12 Binding - Managing Real Binding : Doctor Bob Specialty: Cardiologist Status: Good Standing User: 12345@sunnybrook License: CPSO# 6789 Registry Diet. 12

13 Service Entitlement - Managing User Access View Drugs Can Doctor Bob access the View Drugs service? Service Entitlement Entitlement Rules: Subject must have identity proofing of AL2 or higher Subject must have authenticated at an AL2 level Service request must be under the authority (UAO) of: a HIC based institution; or a regulated provider in good standing from the following colleges (Physicians and Surgeons, Dental Surgeon, Midwife, Nurse Practitioner but not Nurse, Optometrist, Pharmacist, or Podiatrist); or A delegate of the above regulated providers etc 13

14 Federation Technical Standards Federation Prescribed Not Prescribed Provincially Shared Remote Portlets (WSRP2) s ehealth Ontario Examples: SAML2 AD Integration Custom SSO s Direct Service Request (SOAP, SAML2, Service Specific Message Type eg. HL7v2or3 ) Other POS s 14

15 Services Limited Production Release Family Physician Hospital Based Clinician Province Wide Clinician mytoh Ottawa Hospital A GTA Hospital ehealth Ontario Gadgets ehealth Context Aware Framework Domain Repositories Registries Knowledge Resources Lab Drug Immunization Client User Preferences Publications 15

16 Questions Thank you for your interest. Follow-up question can be directed to Abid Malik Director, Vendor Relations