Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
MichiganHealthInformationNetwork
SingleSign‐OnImplementationGuide
Version10August18,2015
iiCopyright 2015 Michigan Health Information Network Shared Services
Document History
Date Version Section(s)Revised Description Modifier8/28/14 1 All InitialDraft Talley
8/29/14 2 Multiple Rewording,EditedDataFlowDiagrams,GeneralReview
TalleySeggieWard
9/4/14 3 Multiple AddedURLsforandupdatedlinks
Talley
9/11/14 4 Multiple Providedlanguage. Talley
9/16/14 5 Multiple Generalcleanup Livesay
9/17/14 6 All Movedtonewtemplate Seggie
9/23/14 7 Multiple UpdateURLlanguageandLinkswithsomedefinitions
Talley
8/11/15 8 All Movetonewtemplate,addedlanguage.
Baker
8/17/15 9 All Review,edits,notesforcompletion
D.Livesay
8/18/15 10 3 AdditionalOnboardingdocumentation
Baker
8/24/15 11 All Review,edits D.Livesay
8/25/15 12 All Finaldraftforreview D.Livesay
iiiCopyright 2015 Michigan Health Information Network Shared Services
Abbreviations and Acronyms
AD ActiveDirectoryCAS PingIdentity’sCloudAccessServiceCMS CentersforMedicare&MedicaidServicesCSP CredentialServiceProviderHIPAA HealthInsurancePortabilityandAccountabilityActHISP HealthInformationServiceProviderIdP IdentityProviderIEH IdentityExchangeHubISO InternationalOrganizationforStandardizationJIT Just‐In‐TimeLoA LevelofAssuranceMiHIN MichiganHealthInformationNetworkSharedServicesNIST NationalInstituteofStandardsandTechnologyPIV PersonalIdentityVerificationPO ParticipatingOrganizationQO QualifiedOrganizationRA RegistrationAuthorityRMF RiskManagementFrameworkRP RelyingPartySAML SecurityAssertionMarkupLanguageSP ServiceProviderSSN SocialSecurityNumberSSO SingleSign‐OnTDSO TrustedDataSharingOrganizationTDSOA TrustedDataSharingOrganizationAgreement
1Copyright 2015 Michigan Health Information Network Shared Services
Table of Contents Document History ......................................................................................................................................... ii
Abbreviations and Acronyms ....................................................................................................................... iii
Table of Contents ......................................................................................................................................... 1
1 Introduction .......................................................................................................................................... 2
1.1 Purpose of Use Case...................................................................................................................... 2
1.2 Data Flow and Actors .................................................................................................................... 3
2 Overview ............................................................................................................................................... 4
2.1 Connecting to the Identity Exchange Hub .......................................................................................... 4
3 Onboarding Process ................................................................................................................................... 4
3.1 Initial Onboarding ............................................................................................................................... 4
3.1.1 Initial Legal Onboarding Process .................................................................................................. 5
3.1.2 Initial Technical Connectivity Onboarding Process ...................................................................... 5
3.1.3 Initial Technical Connectivity Testing ......................................................................................... 16
3.2 Onboarding Additional Applications ................................................................................................. 19
4 Resources and Specifications ................................................................................................................... 20
4.1 Identity Issuance and Authentication ............................................................................................... 20
4.1.1 Assurance Level 0 ....................................................................................................................... 21
4.1.2 Assurance Level 1 ....................................................................................................................... 21
4.1.3 Assurance Level 2 ....................................................................................................................... 21
4.1.4 Assurance Level 3 ....................................................................................................................... 22
4.1.5 Assurance Level 4 ....................................................................................................................... 23
4.2 General Requirements ...................................................................................................................... 24
4.2.1 Logging Requirements ............................................................................................................... 25
4.2.1 Additional Standards Organizations .......................................................................................... 26
4.3 SAML Attributes ................................................................................................................................ 27
4.3.1 List of Attributes......................................................................................................................... 27
4.3.2 Attribute Definitions .................................................................................................................. 28
4.3.3 Just In Time Account Creation ................................................................................................... 30
5 Troubleshooting ....................................................................................................................................... 30
6 Legal Advisory Language .......................................................................................................................... 31
2Copyright 2015 Michigan Health Information Network Shared Services
1 Introduction 1.1 Purpose of Use Case
Currently the task of electronically accessing health information often means logging into multiple, disconnected networks, portals or databases, meaning users must maintain and remember unique login IDs and passwords for each data source. This creates obvious productivity-draining issues resulting from forgotten login information, recovering and resetting passwords, and auto-lockout after multiple failed login attempts, as well as security risks inherent in users writing down passwords or keeping them simple or identical to ease memorization. The issues multiply with each additional login and password combination that a user must maintain, creating additional security risks and potentially taking health professionals’ valuable time away from patient care. Popular Internet companies have enabled users to employ one login ID and password to access multiple web sites. For example, a Google login ID and password now also accesses Facebook, YouTube, LinkedIn and a growing list of web sites that enable shared ‘identities.’ This ability to ‘share’ one identity across multiple networks, web sites or software applications is popularly called Single Sign-On or SSO and gained immediate acceptance as users enjoyed the freedom from remembering so many unique login/password combinations. Single Sign-On applied to health information can similarly solve issues inherent in having to access multiple data sources, but when using data sources that provide access to Protected Health Information (PHI) we must additionally consider federal laws and regulations regarding who may access a person’s PHI. Specifically, on the public Internet there is no standard way to verify someone’s identity, so in the world of health information SSO, a shared login ID and password should only be provided to someone whose identity has been thoroughly verified. This Single Sign-On Use Case leverages a body of technology and legal trust called Federated Identity Management (FIdM) which consists of Policies, Practices and Protocols which are defined below and more fully described in the SSO Use Case Implementation Guide. These Policies, Practices and Protocols are the three major components of FIdM to allow Federated Organizations to utilize trusted identities together.
3Copyright 2015 Michigan Health Information Network Shared Services
1.2 Data Flow and Actors
FormoreinformationaboutthisUseCase,refertothedocumentslinkedbelow:
UseCaseSummary:http://mihin.org/wp‐content/uploads/2013/07/MiHIN‐UCS‐Single‐Sign‐On‐v28‐published‐09‐16‐15.docxUseCaseAgreement:http://mihin.org/wp‐content/uploads/2013/07/MiHIN‐UCA‐Single‐Sign‐On‐PUBLISHED‐v9‐08‐17‐15.docx
4Copyright 2015 Michigan Health Information Network Shared Services
2 Overview 2.1 Connecting to the Identity Exchange Hub
TrustedDataSharingOrganizations(TDSOs)thathaveexecutedtheSingleSign‐OnUseCaseAgreementwillconnecttotheIdentityExchangeHub(IEH)usingthePingIdentityPingOneCloudAccessService(CAS).OnceconnectedtotheIEH,aTDSOwillbeabletoshareauthenticationinformationand/orapplicationaccessforthepurposeofallowingparticipantstoemploysinglesign‐onformultiple,disparatenetworksofotherTDSOsthataresignedupfortheSingleSign‐OnUseCase.IdentityProvidersareparticipatingorganizationsthathaveoneormoreindividualsloggingintoaccessapplicationsthroughSingleSign‐On.TheseIdentityProviderscanmanageandassignrightstotheirusers’identitiesforaccessingvariousapplications.Theserightsaremanagedandassignedbyinclusioningroupswithspecificaccesspermissions.ThisfunctionalityallowsanIdentityProvidertoselectivelyshowonlytheapplication(s)thatwouldbeappropriateforeachparticulargroupofindividualswithinanorganization.Forexample,aconsumerwouldnotneedtoaccessanapplicationintendedonlytobeusedbyhealthcareprofessionalsandviceversa.CurrentlyPingOneallowsconnectionsusingthefollowingmethods:
1.AnySAML2.0enabledidentitymanagementplatform2.PingFederate3.ActiveDirectory(AD)Connect4.Otherconnectionoptionsavailableonrequest,mayrequireadditionalcharges
PleaseseethePingOneDataSheetformoreinformationaboutthetechnicalrequirementstoconnectwiththePingOneCloudAccessService:
https://www.pingidentity.com/content/dam/pic/downloads/resources/data‐sheets/pingone‐data‐sheet.pdf
3 Onboarding Process 3.1 Initial Onboarding
OrganizationswishingtoparticipateinthisoranyotherUseCasewithMiHINmustcompletelegalandtechnicalconnectivityonboardingprocesses.Theseonboardingprocessesmayhappenconcurrently:theorganizationcanreviewandcompletelegalagreementswithMiHINwhilesimultaneouslyestablishingandtestingtechnicalconnectivity.Thetwoprocessesaredescribedinmoredetailbelow.Toinitiateonboarding,[email protected].
5Copyright 2015 Michigan Health Information Network Shared Services
3.1.1 Initial Legal Onboarding Process ThelegalonboardingprocessatMiHINbeginswithreviewandexecutionofaTrustedDataSharingOrganizationAgreement(TDSOA.)ExecutionofthisagreementallowsanorganizationtobecomeaQualifiedOrganization(QO)andenterintooneormoreUseCasesviaUseCaseAgreements.TherearevariousTDSOAsfordifferentkindsoforganizations,availableforreviewat:http://mihin.org/about‐mihin/resources/mihin‐legal‐document‐templatesAnorganizationcanthenenterintoanunlimitednumberofUseCaseswithMiHIN.UseCasescurrentlyavailableforparticipationarelocatedatthefollowinglinks:http://mihin.org/about‐mihin/resources/use‐cases‐in‐production/http://mihin.org/about‐mihin/resources/use‐cases‐in‐pilot/
3.1.2 Initial Technical Connectivity Onboarding Process ThetechnicalconnectivityonboardingprocesswithMiHINbeginswithan“onboardingkickoff”meeting.DuringthismeetingtheMiHINoperationsteamguidesanorganizationthroughstep‐by‐stepdetailstoestablishandtestconnectivity,andanswersanyquestionsregardingthetechnicalconnectivityonboardingprocess.
3.1.2.1 Connecting an Identity Provider to the Identity Exchange Hub
Followingtheonboardingkickoffmeeting,organizationswillbeginconnectivitysetupwhentheMiHINIdentityExchangeHubAdministratorinvitesaTDSOtoparticipateintheIdentityExchangeHub(IEH).TheTDSOwillreceiveanautomatedemailfromPingIdentitycontainingalinktocreateanaccountinPingOneconnectedtotheIdentityExchangeHub.
Followthestepsoutlinedonthescreenshotsbelowtocompleteconnectivitysetup.
6Copyright 2015 Michigan Health Information Network Shared Services
3.1.2.1.1 INITIAL CONNECTIVITY STEPS FOR ALL TYPES OF IDENTITY PROVIDERS
ScreenOne:EmailfromPingIdentity
Clickthe‘Activate’buttonintheautomatedemailtologinandcreateanaccount.
NOTE:dependingonyouremailsettingsthisbuttonmayappearasalink.
ScreenTwo:SetPassword
YouwillneedtocreateapasswordforyourPingOneaccountandclick‘Submit.’Theemailaddressthatreceivedtheoriginalinvitationwillbeusedastheusernamefortheaccount.
7Copyright 2015 Michigan Health Information Network Shared Services
ScreenThree:TermsandConditions
ReadthePingOneTermsandselect‘AgreeandProceed’tofinishsetup.
ScreenFour:Dashboard
OntheDashboardscreenselect‘FinishyourSetup,’thenselect‘ConnecttoanIdentityRepository’onthefollowingscreen.
8Copyright 2015 Michigan Health Information Network Shared Services
ScreenFive:Settings
3.1.2.1.2 REMAINING STEPS FOR CONNECTING A SAML 2.0 IDENTITY PROVIDER
ScreenSix:SelectIdentityRepository
Select‘3rdPartySAML’astheIdentityRepositorytowhichyouwanttoconnect,andclick‘Next’.
ScreenSeven:ConfigureIDPConnection
9Copyright 2015 Michigan Health Information Network Shared Services
Next,selectthe‘DownloadthePingOneMetadataandUploadittoyourIDP’radiobutton.Clickthe‘DownloadPingOneMetadata’buttontosavetheconnectionmetadatafiletoyourcomputer.YouwillneedtouploadthisfiletoyourIdentityProvider.ThemethodforuploadingthisfilewilldependonyourchosenIdentityProvider.OncethefilehasbeenuploadedtotheIdentityProviderclick‘Next.’
ScreenEight:ConfigurePingOneConnection
NextyouwillneedtouploadyourIdentityProvider’sconnectionmetadatatoPingOne.Todothis,firstdownloadtheconnectionmetadatafilefromyourIdentityProviderandsaveittoyourcomputer.Then,undertheConfigureyourPingOneConnectionsection,choosethe‘ImportYourIDPConnectionMetadata’radiobutton,selecttheconnectionmetadatafileyoujustdownloadedfromyourIdentityProvidertoimport,andclickSavetouploadthefiletoPingOne.
YouhavenowsuccessfullyconnectedtotheIdentityExchangeHub!
10Copyright 2015 Michigan Health Information Network Shared Services
3.1.2.1.3 REMAINING STEPS FOR CONNECTING WITH PINGFEDERATE
ScreenNine:SelectandIdentityRepository
Select‘PINGFEDERATE’astheIdentityRepositorytowhichyouwanttoconnect,andclick‘Next’.
ScreenTen:IdentifyPingFederateVersion
SelectthePingFederateVersionthatyouhaveinstalledonyourserver,andclick‘Next’.
11Copyright 2015 Michigan Health Information Network Shared Services
Screen11:ChooseYourServerPlatform
Selecttheserverplatform.
Screen12:DownloadPingFederate
IfyoudonotalreadyhavePingFederateinstalledyoucandownloadithereusingthe‘DownloadPingFederate’button.
FormoreinformationoninstallingPingFederateyoucanreviewthedocumentationonthePingIdentitywebsite:https://www.pingidentity.com/en.html.
IfyoualreadyhavePingFederateinstalledclick‘Next’.
12Copyright 2015 Michigan Health Information Network Shared Services
Screen13:ConfigurePingFederate
YouwillneedtoenteranActivationKeyaspartoftheconnectionsetupinPingFederate.ThestepstoconnectPingFederatewithPingOnedifferbythePingFederateversionandareoutlinedintherespectivePingFederatesetupdocumentationon:https://www.pingidentity.com/en.html.
OncePingFederatehasbeenproperlyconfiguredclick‘Finished’.
YouhavenowsuccessfullyconnectedtotheIdentityExchangeHub!
3.1.2.1.4 REMAINING STEPS FOR CONNECTING WITH ADCONNECT
Screen14:SelectandIdentityRepository
Select‘ADCONNECT’astheIdentityRepositorytowhichyouwanttoconnect,andclick‘Next’.
13Copyright 2015 Michigan Health Information Network Shared Services
Screen15:DownloadADConnect
DownloadADConnectusingthe‘DownloadADConnect’button,andclick‘Next’.
Screen16:SetUptheProductKey
CreateaProductkeythatyouwilluseduringtheADConnectinstallationprocess,andclick‘Next’.
14Copyright 2015 Michigan Health Information Network Shared Services
Screen17:InstallADConnect
NextyouwillneedtoruntheinstallerforADConnectthatyouhavedownloaded.YouwillusetheOrganizationIDshownabovealongwiththeProductKeyyoucreatedpreviouslyduringtheinstallationprocess.
Screen18:EnterOrganizationIDandProductKey
TheabovescreenshotisfromtheADConnectInstaller,youwillneedtocopytheOrganizationIDfromthePingOneportalandentertheProductKeyyoucreatedhere.Oncebothareenteredclick‘Activate’ontheinstaller.Youthencanselect‘Next’ontheinstallerandfinishtheinstallationofADConnect.
15Copyright 2015 Michigan Health Information Network Shared Services
Screen19:VerifyADConnectInstallation
Aftertheinstallationiscomplete,returntothePingOnePortalandclickthe‘VerifyInstallation’button.Oncethesystemverifiestheinstallationitwilldisplayagreen“Configured”messageandyoucanclick‘Next’.IfyouhaveanyissueswithverifyingtheinstallationpleasefollowtheinstructionsprovidedbyPingOneorcontacthelp@mihin.org.
Screen20:ADConnectConfiguration
Configuretheremainingoptionsbasedonyoursystemandclick‘Save’.
YouhavenowsuccessfullyconnectedtotheIdentityExchangeHub!
16Copyright 2015 Michigan Health Information Network Shared Services
3.1.2.2 Connecting a Service Provider to the Identity Exchange Hub
ServiceProviders(organizationsprovidingapplicationsforaccessthroughtheIdentityExchangeHub)followamoreunique,individualizedprocesstoconnect.TheMiHINIdentityExchangeHubAdministratorwillworkdirectlywitheachServiceProvidertoconfiguretheIdentityExchangeHubandtheServiceProvider’sapplicationtoenableconnectivity.ThetwopartieswillexchangemetadatafilesandtheServiceProviderwillprovidealistofallattributestheapplicationacceptsincludingtheattributesthatarerequiredforausertoaccesstheapplication.
Toinitiateconnectivityasaserviceprovider,[email protected].
3.1.3 Initial Technical Connectivity Testing 3.1.3.1 Testing connectivity between Identity Exchange Hub and Identity Provider
BeforetestingconnectivitywiththeIdentityExchangeHubpleasemakesureyouhaveaddedthePingIdentitySingleSign‐Onportaltoyourwebportal.Thisprocesswillbecoveredintheinitialonboardingkickoffmeeting.
OncethePingIdentitySingleSign‐Onportalisaddedtoyourwebportal,simplylogontothePingportalfromyourwebportal.ThePingIdentityportalshouldlooksimilartothebelowscreenshot.NOTE:Theapplicationsshownonthispagewilldependonwhichapplicationshavebeenconfiguredfortheuser’sgroupasdesignatedbytheIdentityProvider.TolearnaboutconfiguringgroupspleasereviewtheEndtoEndTestingsectionofthisdocument.
Screen21:ExampleLoginPageforPingIdentitySingleSign‐OnPortal
3.1.3.2 Connectivity Troubleshooting
IfyouarehavingconnectionissueswithPingOneyoucanusetoolssuchastheSSOtraceradd‐onforFirefox,https://addons.mozilla.org/En‐us/firefox/addon/sso‐tracer/.AfterlaunchingtheSSOTracerfromthetoolsmenu,reattempttheconnectionthatfailedinFirefox.IntheSSOTracerwindowthatopenedwhenlaunchingtheapplication,youshouldseealloftheHTTP(S)trafficfromtheFirefoxbrowserincludingtheSAML.Thiscanbeausefultooltoverifythecorrectinformationisbeingtransmitted.Ifyouneedhelpinterpretingthisinformationcontacthelp@mihin.org.
17Copyright 2015 Michigan Health Information Network Shared Services
Screen22:MetadatadisplayfromSSOTraceradd‐onforFirefox
3.1.3.3 End‐to‐End connectivity testing from Identity Provider to Service Provider
Gotothe“Setup”tabinthePingOneadminportalandthenclickontheDockConfigurationsubtabasshowninScreen23below.Selectthecheckboxto‘ShowAdvancedSettings.’
ThiswilldisplaytheattributesthatneedtobemappedasshowninScreen24belowsoyoucancorrectanydiscrepancieswiththedefaultattributemappingstomatchthenamesoftheattributesbeingsentbytheIdentityProvider.
NOTE:Valuesmightnotbethesame–names/attributesfromeachidentityprovidermaybedifferent,andmustbemappedtoPingOne.
Screen23:DockConfiguration
18Copyright 2015 Michigan Health Information Network Shared Services
Screen24:AdvancedSettings
Nextyouwillneedtodefineandconfigureyourusergroups,startingwiththegroupname.Avalidgroupnameisthevaluepassedinthe“memberOf”attributeshowninthepreviousscreen.SelecttheUserstab,andtheUserGroupssub‐tabinthatsectiontoeditoraddnewUserGroups.
Screen25:UserGroups
Ifnotallpossiblevaluesofthe“memberOf”attributearecoveredbythecurrentlistofgroupnames,anewgroupcanbeaddedusingthe“AddNewGroup”button.Youcanaddorremoveaccesstoapplicationswithinagroupbyusingthe“Edit”button.
NOTE:Allofthesevaluesandattributesarecasesensitive.
Verifythatalltestgroupstobeusedforend‐to‐endtestinghavethecorrespondingtestServiceProviderApplicationlistedinthecorrectgroupunderthe“UserGroups”tab.IdentityProvidersareinvitedtoconnectwithServiceProviderApplicationsbytheMiHINIdentityExchangeHubAdministratorandtheprocesstoconfigureeachoftheapplicationsisthesameastheprocessoutlinedinSection3.2below.
19Copyright 2015 Michigan Health Information Network Shared Services
Screen26:EditingGroupApplicationPermissions
TheIdentityProvidercanrestrictaccesstocertainapplicationsonagrouplevelbyselecting‘Edit’forthegrouponthe‘User’page,anddeselectinganyapplicationthegroupshouldnotbeabletoaccess.
NOTE:Tocontinuetesting,pleasemakesurethetestidentityyouareusingisinthecorrectgroupwiththecorrectapplicationassignedtothatgroup.
Asuccessfulconnectionwillallowtheusertoopenthetargetapplicationbeingusedforend‐to‐endtestingfromthePingSingleSign‐OnPortalandtheuserwillbeautomaticallysignedintothatapplication.Incaseofissues,pleasefollowthesametroubleshootingprocedureswithFirefox’sSSOTracerdescribedinSection3.1.3.2toverifyallmappingswerecorrectandtheproperattributesarebeingsent.
NOTE:IfthetestapplicationdoesnotsupportJustInTimeaccountcreation,userswouldneedtoalreadypossessanaccountwiththeServiceProviderApplicationthattheyaretryingtoaccessforinstantlogintothatapplication.
3.2 Onboarding Additional Applications OnceanewapplicationisaddedtotheSSOUseCase,theMiHINIdentityExchangeHubAdministratorwillsendinvitationstoIdentityProviderstoaddthenewapplicationtotheirUserGroups.TheIdentityProvider’sadministratorforthePingportalwillreceiveanemailcontainingalinkthatwillinitiateconfigurationofthenewapplication.
20Copyright 2015 Michigan Health Information Network Shared Services
Screen27:NewApplicationInvitationEmail
The Identity Provider’s administrator will be asked to confirm names of the Identity
Provider’s Attributes that are mapped to the Service Provider’s Application Attributes.
Screen28:AttributeMappingforNewApplication
OncethemappingconfigurationtothenewServiceProviderApplicationiscomplete,theIdentityProvider’sAdministratorshouldfollowstepsunderSection3.1.3.3End‐To‐EndtestingfromIdentityProvidertoServiceProviderabovetoensureallfieldsareproperlyconfigured.
4 Resources and Specifications 4.1 Identity Issuance and Authentication
ThissectionisintendedtoproviderequirementsforidentityproofingandauthenticatinganindividualbasedontheNationalInstituteofStandardsandTechnology(NIST)LevelsofAssurance(LoA)asoutlinedinNIST800‐63‐2.ThenotionofLevelofAssuranceisanimportantconceptforParticipatingOrganizations(POs)thathavesignedtheSingleSign‐OnUseCaseAgreement.POsare
21Copyright 2015 Michigan Health Information Network Shared Services
requiredtounderstandtheLevelsofAssuranceoutlinedinNIST800‐63‐2andtoensureallrequirementsandproceduresoutlinedinthespecificationarefollowed.OtherPOsaremakingdecisionsbasedontheLevelofAssuranceindicatedintheattributesofatransaction,soitisimperativethatallPOsusetheNIST800‐63‐2specificationwhendeterminingiftheirpolicies,proceduresandimplementationwarrantacertainlevelofassurance.Sections5,6and7ofNIST800‐63‐2,whichdiscusstherequirementsforIdentityIssuanceandIdentityProofing,Tokens,andAuthenticationandCredentialManagementrespectively,shouldbefullyunderstoodbyusersofthisImplementationGuide.
4.1.1 Assurance Level 0 Noassurancesarebeingmadeabouttheidentityoftheuserinanyway.
4.1.2 Assurance Level 1 Noidentityproofingclaimsaremadeabouttheuserbutsomeassuranceisprovidedthatthepersonwhocreatedtheaccountisthesameasthepersonaccessingtheaccountnow.Atlevel1,onlineguessingandreplayattacksshouldbeprevented.Formoreinformationaboutthesecurityrequirementsforlevel1refertoNIST800‐63‐2.
4.1.2.1 Authentication
TheauthenticationmechanismusedbytheproviderofferssomeassurancethatthesameClaimantwhoparticipatedinprevioustransactionsisaccessingtheprotectedtransactionordata.Assurancelevel1allowsawiderangeofavailableauthenticationtechnologiestobeemployedandpermitstheuseofanyofthetokenmethodsofLevels2,3,or4specifiedinNIST800‐63‐2.Ifatokenisused,successfulauthenticationrequiresthattheClaimantprovethroughasecureauthenticationprotocolthattheheorshepossessesandcontrolsthetoken.
4.1.3 Assurance Level 2 Identityproofingisrequiredforassurancelevel2andabovebeforeissuingtheidentity.Identityproofingcanbeperformedinpersonorremotely.Inadditiontopreventingagainstattacksmentionedinlevel1,level2shouldalsoaddresseavesdropperattacks.Formoreinformationaboutthesecurityrequirementsforlevel2refertoNIST800‐63‐2.
4.1.3.1 Identity Proofing
In‐PersonIdentityProofing:ApplicantmustpossessavalidcurrentprimarygovernmentpictureIDthatcontainstheApplicant’spictureandeitheraddressofrecordornationalityofrecord.RegistrationAuthorityinspectsphotoIDandcomparespicturetoApplicant.Credentialsareissuedinawaytoconfirmclaimedaddressorphonenumber.
RemoteIdentityProofing:ApplicantmustpossessavalidcurrentgovernmentIDnumberandafinancialorutilityaccountnumber.RegistrationAuthority(RA)inspects
22Copyright 2015 Michigan Health Information Network Shared Services
bothIDandaccount(e.g.forcorrectnumberofdigits).TheRAmustverifyeitherthegovernmentIDoraccountnumberviarecordchecks,andconfirmthepersonalinformationintherecordsareconsistentwiththeapplicationandsufficienttoidentifyauniqueindividual.Utilityaccountnumberverificationcanbedonebyverifyingknowledgeofrecentaccountactivity.RAalsoverifiesthroughonlinevideothatIDpicturematchesapplicant.
4.1.3.2 Authentication
Level2providessinglefactorremotenetworkauthentication.AwiderangeofavailableauthenticationtechnologiescanbeemployedatLevel2.Forsinglefactorauthentication,MemorizedSecretTokens,Pre‐RegisteredKnowledgeTokens,Look‐upSecretTokens,OutofBandTokens,andSingleFactorOne‐TimePasswordDevicesareallowedatLevel2.ThislevelofassurancealsopermitsanyofthetokenmethodsofLevels3or4.Ifusingatoken,successfulauthenticationrequiresthattheClaimantprovethroughasecureauthenticationprotocolthatheorshecontrolsthetoken.Onlineguessing,replay,sessionhijacking,andeavesdroppingattacksareresisted.Protocolsarealsorequiredtobeatleastweaklyresistanttoman‐in‐the‐middleattacksasdefinedinSection8.2.2ofNIST800‐63‐2.Long‐termsharedauthenticationsecrets,ifused,areneverrevealedtoanyotherpartyexceptVerifiersoperatedbytheCredentialServiceProvider(CSP);however,sessionsharedsecretsmaybeprovidedtoindependentVerifiersbytheCSP.InadditiontoLevel1requirements,assertionsareresistanttodisclosure,redirection,captureandsubstitutionattacks.ApprovedcryptographictechniquesarerequiredforallassertionprotocolsusedatLevel2andabove.
4.1.4 Assurance Level 3 Identityproofingisrequiredforassurancelevel3beforeissuingtheidentity.Identityproofingcanbedoneinpersonorremotely.Inadditiontopreventingagainstattacksmentionedinlevel1and2,level3shouldalsoshouldaddressverifierimpersonationandman‐in‐the‐middleattacks.Formoreinformationaboutthesecurityrequirementsforlevel3refertoNIST800‐63‐2.
4.1.4.1 Identity Proofing
In‐PersonIdentityProofing:ApplicantmustpossessavalidcurrentprimarygovernmentpictureIDthatcontainstheApplicant’spictureandeitheraddressofrecordornationalityofrecord.RegistrationAuthorityinspectsphotoID,comparespicturetoApplicant,verifiesviatheissuingagency,andconfirmsthatthepersonalinformationmatchesthatoftheapplication.Credentialsareissuedinawaythatconfirmsclaimedaddressorphonenumber.
RemoteIdentityProofing:ApplicantmustpossessavalidcurrentgovernmentIDnumberandafinancialorutilityaccountnumber.TheRAmustverifyboththegovernmentIDandaccountnumberviarecordchecks,andconfirmthepersonal
23Copyright 2015 Michigan Health Information Network Shared Services
informationintherecordsareconsistentwiththeapplicationandsufficienttoidentifyauniqueindividual.Utilityaccountnumberverificationcanbedonebyverifyingknowledgeofrecentaccountactivity.RAalsoverifiesthroughonlinevideothatIDpicturematchesapplicant.AtaminimumtherecordscheckofboththegovernmentIDnumberandaccountnumbershouldconfirmthenameandaddressoftheapplicant.Credentialsareissuedinawaytoconfirmtheabilityoftheapplicanttoreceivemessagesattheverifiedphysicalorelectronicaddress.
4.1.4.2 Authentication
Level3providesmulti‐factorremotenetworkauthentication.Atleasttwoauthenticationfactorsarerequired.Level3authenticationisbasedonproofofpossessionoftheallowedtypesoftokensthroughacryptographicprotocol.Multi‐factorSoftwareCryptographicTokensareallowedatLevel3.ThislevelofassurancealsopermitsanyofthetokenmethodsofLevel4.Level3authenticationrequirescryptographicstrengthmechanismsthatprotecttheprimaryauthenticationtokenagainstcompromisebytheprotocolthreatsforallthreatsatLevel2aswellasverifierimpersonationattacks.VarioustypesoftokensmaybeusedasdescribedinSection6ofNIST800‐63‐2.AuthenticationrequiresthattheClaimantprove,throughasecureauthenticationprotocol,thatheorshecontrolsthetoken.TheClaimantunlocksthetokenwithapasswordorbiometric,orusesasecuremulti‐tokenauthenticationprotocoltoestablishtwo‐factorauthentication(throughproofofpossessionofaphysicalorsoftwaretokenincombinationwithsomememorizedsecretknowledge).Long‐termsharedauthenticationsecrets,ifused,areneverrevealedtoanypartyexcepttheClaimantandVerifiersoperateddirectlybytheCSP;however,sessionsharedsecretsmaybeprovidedtoindependentVerifiersbytheCSP.InadditiontoLevel2requirements,assertionsareprotectedagainstrepudiationbytheVerifier.
4.1.5 Assurance Level 4 Identityproofingisrequiredforassurancelevel4beforeissuingtheidentityandmustbedoneinperson.Inadditiontopreventingagainstattacksmentionedinlevels1,2and3,level4shouldalsoshouldaddresssessionhijackingattacks.Formoreinformationaboutthesecurityrequirementsforlevel4refertoNIST800‐63‐2.
4.1.5.1 Identity Proofing
In‐PersonIdentityProofing:ApplicantmustpossessavalidcurrentprimarygovernmentpictureIDthatcontainstheApplicant’spictureandeitheraddressofrecordornationalityofrecord,andasecondindependentGovernmentID,documentorfinancialaccountnumber.RegistrationAuthorityinspectsphotoID,comparespicturetoApplicant,verifiesviatheissuingagency,andconfirmsthatthepersonalinformationmatchesthatoftheapplication.TheRAwillverifythefinancialaccountnumberorinspectthesecondarygovernmentIDandconfirmthatthepersonalinformationis
24Copyright 2015 Michigan Health Information Network Shared Services
consistentwiththeprimaryphotoID.RArecordsacurrentbiometricoftheapplicant.Credentialsareissuedinawaythatconfirmsaddressofrecord.
4.1.5.2 Authentication
Level4isintendedtoprovidethehighestpracticalremotenetworkauthenticationassurance.Level4authenticationisbasedonproofofpossessionofakeythroughacryptographicprotocol.Level4issimilartoLevel3exceptthatonly“hard”cryptographictokensareallowed.ThetokenisrequiredtobeahardwarecryptographicmodulevalidatedatFederalInformationProcessingStandard(FIPS)140‐2Level2orhigheroverallwithatleastFIPS140‐2Level3physicalsecurity.Level4tokenrequirementscanbemetbyusingthePIVauthenticationkeyofaFIPS201compliantPersonalIdentityVerification(PIV)Card.Level4requiresstrongcryptographicauthenticationofallcommunicatingpartiesandallsensitivedatatransfersbetweentheparties.Eitherpublickeyorsymmetrickeytechnologymaybeused.AuthenticationrequiresthattheClaimantprovethroughasecureauthenticationprotocolthatheorshecontrolsthetoken.AllprotocolthreatsatLevel3arerequiredtobepreventedatLevel4.Protocolsshallalsobestronglyresistanttoman‐in‐the‐middleattacks.Long‐termsharedauthenticationsecrets,ifused,areneverrevealedtoanypartyexcepttheClaimantandVerifiersoperateddirectlybytheCSP;however,session(temporary)sharedsecretsmaybeprovidedtoindependentVerifiersbytheCSP.Approvedcryptographictechniquesareusedforalloperations.Allsensitivedatatransfersarecryptographicallyauthenticatedusingkeysboundtotheauthenticationprocess.AtLevel4,“bearer”assertions(asdefinedinSection9ofNIST800‐63‐2)arenotusedtoestablishtheidentityoftheClaimanttotheRelyingParty(RP).“Holder‐of‐key”assertions(asdefinedinSection9)maybeused,providedthattheassertioncontainsareferencetoakeythatispossessedbytheSubscriberandiscryptographicallylinkedtotheLevel4tokenusedtoauthenticatetotheVerifier.TheRPshouldmaintainrecordsoftheassertionsitreceives,tosupportdetectionofacompromisedverifierimpersonatingthesubscriber.
4.2 General Requirements EveryprovidertakingpartintheSingleSign‐OnUseCasemustbeabletocommunicatewiththePingIdentityPingOneCloudAccessService.MoreinformationonthetechnicalrequirementsforaProvidertoconnectwithPingOnecanbefoundat:https://www.pingidentity.com/content/dam/pic/downloads/resources/data‐sheets/pingone‐data‐sheet.pdf.
CurrentlyPingOneallowsconnectionsfromprovidersusingthefollowingmethods:
1.AnySAML2.0enabledidentitymanagementplatform2.PingFederate3.ADConnect
25Copyright 2015 Michigan Health Information Network Shared Services
4.Otherconnectionoptionsavailableonrequest,mayrequireadditionalcharges
TheprovidermustbeawareofthelevelsofassuranceoutlinedinNIST800‐63‐2.TheproviderisresponsiblethatthemethodofconnectingtotheIdentityExchangeHubmeetsalltherequirementsoutlinedintheNISTspecificationtopreventagainstthedifferenttypesofattacksforthehighestLevelofAssurancetransactiontheProviderwillmake.
4.2.1 Logging Requirements 4.2.1.1 Participating Organization
ParticipatingOrganizationshall,ataminimum,logthefollowinginformation:
(i) Date and time Message Content was exchanged and identity (e.g., uniqueidentifier)ofindividualorsystem,asapplicable,accessingtheMessageContent;
(ii) DateandtimeMessageContentwastransmittedthroughtheIdentityExchangePlatform and identity of individual or system, as applicable, transmitting theMessageContent;
(iii) UniquemessageidentifierfortheMessageContentaccessed,sent,orreceived;
(iv) MessageContentaccessed;
(v) Verificationof theuserattributesexchangedwithanyFederatedOrganization;and
(vi) Anyfailures,ornetworkevents.
4.2.1.2 HINHINshall,ataminimum,logthefollowinginformation:
(i) NameofParticipatingOrganizationaccessingtheIdentityExchangePlatform;
(ii) Identity of thePrincipal (e.g., unique identifier)making an access request to aFederatedOrganization;
(iii) Dateandtimetheaccessoccurred;
(iv) SourceIPaddressoftherequest;
(v) Any applicable errormessages received from a FederatedOrganization or theIdentityExchangePlatform.
Exceptasprovidedintheforegoing,HINshallnotbeobligatedtomaintainandshallnotberesponsible foreithermaintainingrecordsofthecontentofanyMessageexchangebetweenthePartiesorinspectingthecontentofsuchMessages.
26Copyright 2015 Michigan Health Information Network Shared Services
4.2.1 Additional Standards Organizations 4.2.1.1 National Institute of Standards and Technology (NIST)
NIST800‐63‐2coversthe“Registration,CredentialIssuanceandMaintenance”profilesfor“E‐Authentication”asstandardguidelines.Section5.3.1definesthegeneralrequirementsperassurancelevelandTable3definesthe“IdentityProofingRequirements.”
ItisrecommendedthatreviewersofthisimplementationguiderefertotheExecutiveSummaryofNIST800‐63‐2fordefinitionsofthefour(4)levelsofassuranceasmostpatientdataexchangeswillmostlikely,afterriskassessment,requireanLOAThree.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800‐63‐2.pdf;
DiagramOne:OverviewofCredentialIssuanceande‐Authentication
Itisfurtherrecommendedthatreadersofthisimplementationguidealsoreview“IdentityProofing”inSection5,“Cryptographickeys”(certificates)inSection6,“TokenandCredentialManagement”inSection7andfinally,SAMLAssertions(2.0)inSection9.
AllusefulNIST800series,ComputerSecurityProfiles,suchasNIST800‐30,“GuidesforConductingRiskAssessments”canbefoundat:
http://csrc.nist.gov/publications;
ItisrecommendedthatreviewersfocusonChapterTwoofthe“GuidesforConductingRiskAssessments”,whichdefinestheFundamentalsoftheRiskAssessmentProcessandChapterThreewhichillustratestheprocessofpreparingtheriskassessment,conductingtheassessment,communicatingtheassessment,andmaintainingtheassessment.
27Copyright 2015 Michigan Health Information Network Shared Services
Each“risk”shouldsystemicallygeneratea“value,”whichquantifiesthelevelofrisktotheorganization,fromwhichcanbeassignedalevelofassurancerelativetoNIST800‐63‐2.
StepsfordeterminingthevaluesoftheriskassessmentaredefinedinSection2.4.3“RiskAssessmentsattheInformationTier”andforthosewishingfurtherguidance,NIST800‐30providesarecommendationtoreviewNIST800‐37,“RiskManagementFramework.”However,NIST800‐30providesthenecessaryinformationforconductingariskassessmentandNIST800‐37isoptional.
NIST800‐145andNIST800‐76‐2arerecommendedforthoseinterestedinNIST“SOACloudStandards.”ForthoseimplementingHIPAASecurityRules,abasicworkingresourceandknowledgeof“HIPAASecurityRules”,NIST800‐66‐Revision1ishighlyrecommended.
4.2.1.2 International Organization for Standardization (ISO)
ReviewofISOstandardsisoptionalforimplementersbutyoumayfindISO27002usefulasitisacollectionofbestpracticesforinformationsecuritymanagementwhichhavebeenagreeduponbyorganizationsnationally.Thefocusisonconfidentiality,(Authorizedaccess),integrity,(Accuracyofdata)andavailability(Authorizedusershaveaccess).ReviewersarerecommendedtofocusonSection2,whichpertainstothescopeofthestandard.Section3providesbestpracticeguidanceonmalware,backup,logging,monitoring,controlofoperationalsoftware,vulnerabilities,andaudit.Section6isforinformationsecurityinsupplierrelationshipsandsupplierservicedeliverysystems.
4.3 SAML Attributes 4.3.1 List of AttributesToparticipateintheSingleSign‐OnUseCase,youwillneedtotransmitthefollowingattributes:
UserAttributesList: RequiredforIdPtoSend1 FirstName Yes2 MiddleInitial No3 LastName Yes4 DisplayName No5 StreetAddress No6 City No7 State No8 ZipCode No9 EmailAddress Yes10 DirectAddress No
28Copyright 2015 Michigan Health Information Network Shared Services
4.3.2 Attribute Definitions 4.3.2.1 First Name
Theuser’slegalfirstname.
4.3.2.2 Middle Initial
Theinitialoftheuser’smiddlename.Iftheuserhasmultiplemiddlenamesthiswillbetheinitialofthefirstmiddlename.
4.3.2.3 Last Name
Theuser’slegallastname.
4.3.2.4 Display Name
Thedisplaynamefortheuser,mayalsobecalledusername.
4.3.2.5 Street Address
Astreetaddresswheretheuserreceivesmail.
4.3.2.6 City
Thecitywheretheuserreceivesmail.
4.3.2.7 State
Thetwo‐letterStateabbreviationwheretheuserreceivesmail.
4.3.2.8 ZIP Code
ThefivedigitZIPcodewheretheuserreceivesmail.
4.3.2.9 Email Address
Anemailaddresswheretheusercanbecontacted.
4.3.2.10 Direct Address
ADirectSecureMessagingAddressissuedtotheuserbyanaccreditedHISPthatallowsforsecuretransferofemail.
4.3.2.11 Phone Number
Aprimary10‐digitphonenumberwheretheusercanbecontacted.
11 PhoneNumber No12 DateOfBirth Yes13 SSN No14 AssuranceLevel Yes15 Role Yes16 GroupName Yes17 UniqueIdentifier No18 NPINumber No19 CommonKeyService No20 Gender No
29Copyright 2015 Michigan Health Information Network Shared Services
4.3.2.12 Date of Birth
ThedatewhentheuserwasborninMM/DD/YYYYformat.
4.3.2.13 SSN
Thelastfourdigitsoftheuser’sSocialSecurityNumber.
4.3.2.14 Assurance Level
Anumberbetween0and4thatrepresentstheLevelofAssurancethattheIdentityProviderauthenticatesthatthepersoniswhotheyclaimtobe.Pleaseviewsection4.1fordetailedinformationabouttherequirementsforeachlevel.
4.3.2.15 Role
Thetypeofpositiontheuserhasattheorganization.CanbeusedwithAssuranceLeveltodeterminethetypeofaccessausergetstoaserviceprovider’sapplication.Thecurrentvalidrolesare“Provider”and“General.”
4.3.2.15.1 PROVIDER
The“Provider”roleisusedforahealthcareprofessional(e.g.adoctorofmedicineorosteopathy,podiatrist,dentist,chiropractor,clinicalpsychologist,optometrist,nursepractitioner,nurse‐midwife,clinicalsocialworker,etc.)whoisauthorizedtopracticebytheStateandperformingwithinthescopeoftheirpracticeasdefinedbyStatelaw.
4.3.2.15.2 GENERAL
The“General”roleisusedforanypersonwhodoesnotmeettherequirementsforanyoftheotherrolescontainedinthissection.
NOTE:Additionalrolesmaybeadded
4.3.2.16 Group Name
ThisvalueisusedtoallowaccesstodifferentapplicationsinthePingportal.AnIdentityProvidercanlimitaccesstocertainapplicationstoonlyusersofcertaingroups.ThevaluesoftheseattributesmustmatchtheconfigurationinthePingportalunderthegroupstab.
4.3.2.17 Unique Identifier
AnidentifierthatisusedbytheIdentityProvidertouniquelyidentifytheuser.
4.3.2.18 NPI Number
Aten‐digitNationalProviderIdentifierassignedbytheCentersforMedicareandMedicaidservices.
4.3.2.19 Common Key Service
TheCommonKeyisasystemidentifierusedforpatientmatchingtohelpidentifyindividuals.
30Copyright 2015 Michigan Health Information Network Shared Services
4.3.2.19 Gender
Avalueindicatingthegenderoftheuser,validvaluesare:“Male,”“Female,”“Other,”and“Unknown.”
4.3.3 Just In Time Account Creation ApplicationscanbeconfiguredtosupportJustInTime(JIT)accountcreation(automaticaccountprovisioning).WhenauserfromaparticipatingIdentityProviderlogsintoanapplicationthatsupportsJITaccountcreationforthefirsttimefromtheIdentityExchangeHub,anaccountforthatapplicationisautomaticallycreatedfortheuser.ThecreationoftheaccountwouldonlyoccurifalldatapointsintheSAMLattributesareproperlyconveyedtotheserviceprovider,whichmayincludeattributesmarkedasnotrequired,butwhicharerequiredforinitialaccountcreation.Forexampleoneapplicationcouldpotentiallyhavemarkedonlyhalfoftheattributesasrequiredtologintoanexistingaccount,butiftheapplicationalsosupportsJITaccountcreationitmayrequirealloftheoptionalattributestobepopulatedtocreateanewaccount.TheServiceProviderhastherighttolimitJITaccountcreationtotransactionswithaminimumlevelofassuranceorotherlimitingfactors,includingbutnotlimitedtouserrole.AssumingtherequirementsaremetthereisnoneedtohaveanyprioraccountsetupwiththeparticipatingserviceswhenlogginginviatheIdentityExchangeHubforthefirsttime.NOTE:Ifadditionalattributesorinformationneedtobecapturedbeyondwhatisavailableinattributeslist,theServiceProviderisresponsibleforprovidingamechanismtocapturetheadditionalattributes.
5 Troubleshooting AlistofcommonquestionsandissuesregardingthePingIdentityPingOneCloudAccessServicecanbefoundat:
https://ping.force.com/Support/PingIdentityCommunityHomeIfexperiencingdifficultiesorhavequestions,pleasecontacttheMiHINHelpDesk: Email:[email protected] Phone:(517)336‐1430
Monday–Friday8:00AM–5:00PM(Eastern)
31Copyright 2015 Michigan Health Information Network Shared Services
6 Legal Advisory Language ThisreminderappliestoallUseCasescoveringtheexchangeofelectronichealthinformation:TheTrustedDataSharingOrganizationAgreement(TDSOA)establishesthelegalframeworkunderwhichParticipatingOrganizationscanexchangemessagesthroughtheHINPlatform,andsetsforththefollowingapprovedreasonsforwhichmessagesmaybeexchanged:
(a) ByhealthcareprovidersforTreatment,Paymentand/orHealthCareOperationsconsistentwiththerequirementssetforthinHIPAA;
(b) PublichealthactivitiesandreportingaspermittedbyHIPAAandotherApplicableLawsandStandards;
(c) Tofacilitatetheimplementationof“MeaningfulUse”criteriaasspecifiedintheAmericanRecoveryandReinvestmentActof2009andaspermittedbyHIPAA;
(d) UsesanddisclosurespursuanttoanAuthorizationprovidedbytheindividualwhoisthesubjectoftheMessageorsuchindividual’spersonalrepresentativeinaccordancewithHIPAA;
(e) ByDataSharingOrganizationsforanyandallpurposes,includingbutnotlimitedtopilotprogramsandtesting,providedthatsuchpurposesareconsistentwithApplicableLawsandStandards;and
(f) ForanyadditionalpurposesasspecifiedinanyUseCase,providedthatsuchpurposesareconsistentwithApplicableLawsandStandards.
UndertheDSA,“ApplicableLawsandStandards”meansallapplicablefederal,state,andlocallaws,statutes,acts,ordinances,rules,codes,standards,regulationsandjudicialoradministrativedecisionspromulgatedbyanygovernmentalorself‐regulatoryagency,includingtheStateofMichigan,theMichiganHealthInformationTechnologyCommission,ortheMichiganHealthandHospitalAssociation,asanyoftheforegoingmaybeamended,modified,codified,reenacted,promulgatedorpublished,inwholeorinpart,andineffectfromtimetotime.“ApplicableLawsandStandards”includesbutisnotlimitedtoHIPAA;thefederalConfidentialityofAlcoholandDrugAbusePatientRecordsstatute,section543ofthePublicHealthServiceAct,42U.S.C.290dd‐2,anditsimplementingregulation,42CFRPart2;theMichiganMentalHealthCode,atMCLA§§333.1748and333.1748a;andtheMichiganPublicHealthCode,atMCL§333.5131,5114a.ItiseachQO’sobligationandresponsibilitytoensurethatitisawareofApplicableLawsandStandardsastheypertaintothecontentofeachmessagesent,andthatitsdeliveryofeachmessagecomplieswiththeApplicableLawsandStandards.Thismeans,forexample,thatifaUseCaseisdirectedtotheexchangeofphysicalhealthinformationthatmaybeexchangedwithoutpatientauthorizationunderHIPAA,theQOmustnotdeliveranymessagecontaining
32Copyright 2015 Michigan Health Information Network Shared Services
healthinformationforwhichanexpresspatientauthorizationorconsentisrequired(e.g.,mentalorbehavioralhealthinformation).
Disclaimer: TheinformationcontainedinthisimplementationguidewascurrentasofthedateofthelatestrevisionintheDocumentHistoryinthisguide.However,NISTpoliciesaresubjecttochange.Therefore,linkstoanysourcedocumentshavebeenprovidedwithinthisguideforreference.MiHINappliesitsbesteffortstokeepallinformationinthisguideup‐to‐date.ItisultimatelytheresponsibilityoftheParticipatingOrganizationandSendingFacilitiestobeknowledgeableofchangesoutsideofMiHIN’scontrol.