Single Sign-On (SSO), Identity Exchange Hub, Remote Identity Proofing

Transcription

1 Single Sign-On (SSO), Identity Exchange Hub, Remote Identity Proofing Brian Seggie Director of Security 1

2 Why are we doing this? Leverage large MICAM investment ($30 M) Improve identity verification to reduce fraud Reduce # of IDs and passwords for participants Simplify healthcare provider workflows Reduce IT staff workload (fewer account creations) Improve security by implementing standards-based processes 2

3 We [providers] (... ) are busily seeing patients and trying to do it as quickly as possible in hospitals, clinics and especially ERs that have no off switch but which do track our quality in part by tracking our speed and efficiency. Thus, we have little time to spend logging on [to systems]. (... ) It [passwords and security] was a nice idea but now it s a poison. It is the law of unintended consequences on steroids. It s all redundant, irrelevant, obnoxious busy work that stands between us and efficiency. If you really insist on it, then make it all biometric (... ). Because tracking usernames and passwords is starting to take up more of our fragile brains than drug doses and diagnoses. And that, my friends, is not good. Edwin Leap, MD Tech January 26, 2015 More time for patients 3

4 Before single sign-on Health Systems Health Plans Direct Secure Messaging HISPs Statewide Health Provider Directory Consent and Advanced Directive Registries State of Michigan MICAM Gift of Life Registry (organ donors) Each system requires a separate user ID and password leading to lost passwords and delays in accessing systems ID: John Robert Password: ************ ID: Jrobert Password: ******** ID: Robert Password: ***** ID: RobertJ Password: ********* ID: Robert.John Password: ***** ID: John.Robert Password: ************ ID: Robert1 Password: ******* Copyright 2015 Michigan Health Information Network Shared Services 4

5 After single sign-on Health Systems Health Plans Direct Secure Messaging HISPs Statewide Health Provider Directory Consent and Advanced Directive Registries State of Michigan MICAM Gift of Life Registry (organ donors) One trusted digital credential to access all needed systems Copyright 2015 Michigan Health Information Network Shared Services 5

6 What are federated Identities? A federated identity is a trusted form of identification such as a login ID and password that can be used to access multiple systems including those outside the home organization. Federated identity management (FIdM) is an arrangement among multiple organizations that lets subscribers use the same identity data to access the resources (services) of other organizations. 6

7 Federated identities for healthcare Federated Identity Management consists of: Policies, Practices, Protocols or the three P s POLICIES: Legal and Trust Framework development The legal agreements that make create trust beyond reproach Trusted Data Sharing Organization Agreements (TDSOA) Use Case Agreements (UCA) PRACTICES: Participant and process implementation Process workflow precise series of steps User Acceptance Testing (UAT) Monitor the process end-to-end walk-through with participants PROTOCOLS: The technical connectivity between systems Identity Proofing NIST, Kantara and DirectTrust Levels of Assurance Standards include SAML 2.0, XACML, JSON, OAUTH, OpenID, UMA 7

8 Policies: Legal framework for trust Leverage the existing MiHIN Legal framework to cover the exchange of trusted identities and federated services: Trusted Data Sharing Organization Agreements Use Case Summaries (UCS) Use Case Agreements (UCA) Single Sign-on Use Case Security requirements Other legal agreements as needed 8

9 DATA SHARING (QDSOA,VQDSOA, CQDSOA, SSOA, SSSOA) Legal infrastructure ORGANIZATION AGREEMENT Definitions Basic Connection Terms Use Case #1 QO Data Sharing Agreements Use Case #2 Use Case #3 Use Case Basic BAA Terms Minimal Operational SLA Contracting & Payment Cyber Liability Insurance Termination Federated Services, Identity Sharing Agreements SSO Use Case #1 Use Case #2 Use Case #3 Use Case Copyright Michigan Health Information Network Shared Services 9

10 NIST Levels of Assurance (LOA) NIST lists Levels of Assurance (LOA) for credentials Project utilizes NIST criteria on whether an ID is trusted for access to specific systems or information to promote LOA 3 Other LOA levels will be supported during the project NIST Levels of Assurance LOA 1 - Little or no confidence exists in the asserted identity LOA 2 - Confidence exists that the asserted identity is accurate LOA 3 High confidence in the asserted identities* LOA 4 Highest level of assurance. Mostly used by U.S. Government *recommended for statewide adoption in HIT by MOAC Security WG 10

11 Practices: Process implementation Defined workflow for providers to obtain trusted identities Tested process with MiHIN interns playing doctors to test the process and application at USPS retail location Monitored providers actually going through process of registering for an LOA 3 identity and using the new credential at both USPS and United Physician sessions Menlo Hi-tech Anthropologists monitored identity registration process for improvements to GUI, training, and provider registration Documented findings with recommendations for registration and authentication process improvements 11

12 Further opportunities Look for more opportunities where federating identities between healthcare organizations can improve efficiencies, workflow, user experience or security Organ Donation Health Systems EHRs Payers Labs Pharmacies Other 12

13 Protocols: Technical connectivity Initial Identity and Service Providers: 2 Large Michigan Hospitals Direct Secure Messaging HISPs Personal Health Records (PHRs) MiHIN Biometric Trusted Identity Provider Statewide Health Provider Directory (HPD) (Salesforce.com) Planned Identity and Service Providers: State of Michigan MiLogin Additional Health Systems and Health Plans Consent and Advanced Directive Registries Patient Portals 13

14 Example metadata - user attributes Example User Attributes List: 1 Name (First/Last) 2 Display Name 3 Person Entitlement, (NIST LOA 1-4) 4 Role (Provider, Consumer, Researcher, etc ) 5 Contact Info ( , Phone) 6 Second Factor / Biometric ID 7 Employee ID (Not ) 8 Common Key 9 National Provider Identifier (NPI) 14

15 Trusted identity registration system Created an Identity Provider (IdP) capable of registering trusted identities that can be exchanged with other trusted organizations Establish identity registration and proofing system at two large Michigan Health Systems Two portable biometric registration systems available that can be moved to any location to register providers Remote Identity Proofing Services Issuing Trusted Identities (RIPSITI) a new option! 15

16 Trusted identity registration sessions Actual Comments That was so easy First Provider, Dr. Robert Jackson registering for LOA 3 with biometric We re done already? Registration session at United Physicians by health system staff 16

17 Biometrics as second factor Fujitsu Palm Scanners Iris Scanners 17

18 USPS digital credential process MiHIN Identity Registration Step 1 Provider presents credentials to passport clerk at USPS retail outlet passport window (or Secretary of State, or other onsite locations) Step 2 Obtain secure biometric identity by scanning palm and/or iris Step 3 Register provider and link biometric template to provider account information Step 4 Digital credential created. Palm/iris scanner can now be used to login, or secure id and password can be used 18

19 First two use cases Single Sign-On Use Case: Basic federation of identities to access systems or information at other organizations Map an ID from one organization to an existing account at another organization Expanded single-sign-on (SSO) Automatic Account Provisioning Use Case: Accounts automatically created and authorization given based solely on extended metadata contained in access request Requires trust beyond reproach Strict policies and procedures and strong legal agreements 19

20 Remote Identity Proofing Service Issuing Trusted Identities (RIPSITI ) (patent pending) Brian Seggie Director of Security

21 Start RIPSITI

22 Accept terms and conditions

23 Select the type of account and option

24 Complete online form

25 Answer credit bureau generated questions

26 Verify government ID

27 Select government identification

28 Use webcam to upload government ID

29 Upload second identification

30 Start live session with registration authority

31 Live session with registration authority

32 Applicant digitally signs form

33 Registration authority digitally signs form

34 Credit Card Payment Pay

35 Complete

36 Applicant Applicant visit RIPSITI website HISP sends username and One Time Password (OTP) to Applicant separately and out ofband RIPSITI 1 ONLINE 9 HISP Provisions and creates account Applicant identification uploaded Sends completed form API sends metadata to HISP to create account RIPSITI Remote Identity Proofing Service Query HPD for Provider NPI information 4 Identity Proofing Process with Live Registration Authority API sends token with metadata to Issue Trusted Identity Service 6 Store session in archive Session Archive API sends to completed form database Capability to send identity proofing metadata to other services using RIPS for identity proofing 8 7 HPD Issue Trusted Identity and/or Direct account ITI Service CKS Service Links record to form Form Archive Issue Trusted Identity Service

37 Welcome to Trusted Identity Biometric Capture Please place right hand on the scanner and select Start Biometric Capture

38 Thank you Please send questions/inquiries to: Brian Seggie Director of Security Jeff Livesay Associate Director Sue Kish Program Manager 38