Single Sign‐On Implementation Guide - MiHIN · SSO, a shared login ID and password should only be...

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


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.


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


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


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.


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.


ScreenThree:TermsandConditions

ReadthePingOneTermsandselect‘AgreeandProceed’tofinishsetup.

ScreenFour:Dashboard

OntheDashboardscreenselect‘FinishyourSetup,’thenselect‘ConnecttoanIdentityRepository’onthefollowingscreen.


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


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!


3.1.2.1.3 REMAINING STEPS FOR CONNECTING WITH PINGFEDERATE

ScreenNine:SelectandIdentityRepository

Select‘PINGFEDERATE’astheIdentityRepositorytowhichyouwanttoconnect,andclick‘Next’.

ScreenTen:IdentifyPingFederateVersion

SelectthePingFederateVersionthatyouhaveinstalledonyourserver,andclick‘Next’.


Screen11:ChooseYourServerPlatform

Selecttheserverplatform.

Screen12:DownloadPingFederate

IfyoudonotalreadyhavePingFederateinstalledyoucandownloadithereusingthe‘DownloadPingFederate’button.

FormoreinformationoninstallingPingFederateyoucanreviewthedocumentationonthePingIdentitywebsite:https://www.pingidentity.com/en.html.

IfyoualreadyhavePingFederateinstalledclick‘Next’.


Screen13:ConfigurePingFederate

YouwillneedtoenteranActivationKeyaspartoftheconnectionsetupinPingFederate.ThestepstoconnectPingFederatewithPingOnedifferbythePingFederateversionandareoutlinedintherespectivePingFederatesetupdocumentationon:https://www.pingidentity.com/en.html.

OncePingFederatehasbeenproperlyconfiguredclick‘Finished’.


3.1.2.1.4 REMAINING STEPS FOR CONNECTING WITH ADCONNECT

Screen14:SelectandIdentityRepository

Select‘ADCONNECT’astheIdentityRepositorytowhichyouwanttoconnect,andclick‘Next’.


Screen15:DownloadADConnect

DownloadADConnectusingthe‘DownloadADConnect’button,andclick‘Next’.

Screen16:SetUptheProductKey

CreateaProductkeythatyouwilluseduringtheADConnectinstallationprocess,andclick‘Next’.


Screen17:InstallADConnect

NextyouwillneedtoruntheinstallerforADConnectthatyouhavedownloaded.YouwillusetheOrganizationIDshownabovealongwiththeProductKeyyoucreatedpreviouslyduringtheinstallationprocess.

Screen18:EnterOrganizationIDandProductKey

TheabovescreenshotisfromtheADConnectInstaller,youwillneedtocopytheOrganizationIDfromthePingOneportalandentertheProductKeyyoucreatedhere.Oncebothareenteredclick‘Activate’ontheinstaller.Youthencanselect‘Next’ontheinstallerandfinishtheinstallationofADConnect.


Screen19:VerifyADConnectInstallation

Aftertheinstallationiscomplete,returntothePingOnePortalandclickthe‘VerifyInstallation’button.Oncethesystemverifiestheinstallationitwilldisplayagreen“Configured”messageandyoucanclick‘Next’.IfyouhaveanyissueswithverifyingtheinstallationpleasefollowtheinstructionsprovidedbyPingOneorcontacthelp@mihin.org.

Screen20:ADConnectConfiguration

Configuretheremainingoptionsbasedonyoursystemandclick‘Save’.



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.


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


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.


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.


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


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


bothIDandaccount(e.g.forcorrectnumberofdigits).TheRAmustverifyeitherthegovernmentIDoraccountnumberviarecordchecks,andconfirmthepersonalinformationintherecordsareconsistentwiththeapplicationandsufficienttoidentifyauniqueindividual.Utilityaccountnumberverificationcanbedonebyverifyingknowledgeofrecentaccountactivity.RAalsoverifiesthroughonlinevideothatIDpicturematchesapplicant.


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.


In‐PersonIdentityProofing:ApplicantmustpossessavalidcurrentprimarygovernmentpictureIDthatcontainstheApplicant’spictureandeitheraddressofrecordornationalityofrecord.RegistrationAuthorityinspectsphotoID,comparespicturetoApplicant,verifiesviatheissuingagency,andconfirmsthatthepersonalinformationmatchesthatoftheapplication.Credentialsareissuedinawaythatconfirmsclaimedaddressorphonenumber.

RemoteIdentityProofing:ApplicantmustpossessavalidcurrentgovernmentIDnumberandafinancialorutilityaccountnumber.TheRAmustverifyboththegovernmentIDandaccountnumberviarecordchecks,andconfirmthepersonal


informationintherecordsareconsistentwiththeapplicationandsufficienttoidentifyauniqueindividual.Utilityaccountnumberverificationcanbedonebyverifyingknowledgeofrecentaccountactivity.RAalsoverifiesthroughonlinevideothatIDpicturematchesapplicant.AtaminimumtherecordscheckofboththegovernmentIDnumberandaccountnumbershouldconfirmthenameandaddressoftheapplicant.Credentialsareissuedinawaytoconfirmtheabilityoftheapplicanttoreceivemessagesattheverifiedphysicalorelectronicaddress.


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.


In‐PersonIdentityProofing:ApplicantmustpossessavalidcurrentprimarygovernmentpictureIDthatcontainstheApplicant’spictureandeitheraddressofrecordornationalityofrecord,andasecondindependentGovernmentID,documentorfinancialaccountnumber.RegistrationAuthorityinspectsphotoID,comparespicturetoApplicant,verifiesviatheissuingagency,andconfirmsthatthepersonalinformationmatchesthatoftheapplication.TheRAwillverifythefinancialaccountnumberorinspectthesecondarygovernmentIDandconfirmthatthepersonalinformationis


consistentwiththeprimaryphotoID.RArecordsacurrentbiometricoftheapplicant.Credentialsareissuedinawaythatconfirmsaddressofrecord.


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


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.


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.


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


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


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.


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)


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


healthinformationforwhichanexpresspatientauthorizationorconsentisrequired(e.g.,mentalorbehavioralhealthinformation).

Disclaimer: TheinformationcontainedinthisimplementationguidewascurrentasofthedateofthelatestrevisionintheDocumentHistoryinthisguide.However,NISTpoliciesaresubjecttochange.Therefore,linkstoanysourcedocumentshavebeenprovidedwithinthisguideforreference.MiHINappliesitsbesteffortstokeepallinformationinthisguideup‐to‐date.ItisultimatelytheresponsibilityoftheParticipatingOrganizationandSendingFacilitiestobeknowledgeableofchangesoutsideofMiHIN’scontrol.

Single Sign‐On Implementation Guide - MiHIN · SSO, a shared login ID and password should only be...

Documents

Transcript of Single Sign‐On Implementation Guide - MiHIN · SSO, a shared login ID and password should only be...