Integrated User and Access Management 1

General Principles

Policy Enforcement Model ( 1 / 8 ) based on generic Policy Enforcement Model Acronyms Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Information Point (PIP) Policy Administration Point (PAP) Access Control Principles Role Based Access Control (RBAC) Attribute Based Access Control (ABAC) AuthoriZation Based Access Control (ZBAC)

Policy Enforcement Model ( 2 / 8 ) A user wants access to an application

Policy Enforcement Model ( 3 / 8 ) PEP contacts PDP with question: What are the attributes of user X with identification attributes Y,Z? What are the roles that user X with identification attributes Y,Z? Has user X with identification attributes Y,Z access to APP1?

Policy Enforcement Model ( 4 / 8 ) PDP answers the question that PEP has posed.

Policy Enforcement Model ( 6 / 8 ) based on the information retrieved from the PDP PEP grants access or not to the application

Policy Enforcement Model ( 7 / 8 )

Policy Enforcement Model ( 8 / 8 ) manage different policies managed by person(s) responsible secured environment

eHealth-Certificates: specifications x509v3 certificate Issued by GovernmentCA (fedict) Current Subject specifications CN = Logical name of the certificate O = Official name of the organization OU = Type of identification no. e.g. CBE / NIHII / … SerialNumber = Identification no. of the organization

eHealth-Certificates: procedure ( 1 / 2 ) The Certificate responsible of the organization creates a Certificate Signing Request (CSR) The legal representative of the organization fills in the proxy form The representative sends the proxy form to Smals Regular mail Smals - Rue du Prince Royal 102 -1050 Bruxelles Email subject: eHealth – identification certificate proxy accesscoordination@smals.be Fax: 02/511.12.42 (Barbara Meyers / Sara Vander Meeren)

eHealth-Certificates: procedure ( 2 / 2 ) The Certificate responsible sends an email with the generated CSR as attachment. subject: eHealth – identification certificate CSR accesscoordination@smals.be As reply on his email, he obtains the public key of the certificate.

SSO @ web

Access to application: principle ( 1 / 3 )

Access to application : principle ( 2 / 3 ) eHealth determines a first authorization level When user has no access Applications don't receive the identity of the user Applications only receive 'not authorized' When user has access Applications receive the identity of the user the chosen organization or proxy the attributes desired by the application collected from the different VAS Applications determine a second authorization level

Access to application : principle ( 3 / 3 ) Mapping UAM concepts to eHealth PIP : VAS (+ UM, Mandates, etc.) PAP : policy repository eHealth When accessing an application eHealth is the PDP eHealth plays part of the PEP role first authorization level

Access to an application : example ( 1 / 4 ) Example : Cancer Registration Requested profiles User in a hospital Doctor (type A or type B) Recognized by the FPS-PH Recognized by the NIHII Recognized by the hospital (as doctor type A or B) Administrative worker Works in the name of one or several doctors. employee of the Belgian Cancer Registry

Access to an application : example ( 2 / 4 )

Access to an application : example (3/4) <authorisationResponse> <ticketnumber>1234567890123</ticketnumber> <service>RC</service> <user> <inss>80062416363</inss> <firstName>Mock</firstName> <lastName>Person</lastName> <organisation> <name>MOCK HOSPITAL</name> <id>71080016</id> <type>NIHII</type> <subtype>HOSPITAL</subtype> </organisation> <languageCode>FR</languageCode> </user>

Access to an application : example ( 4 / 4 ) <data> <subject> <id>80062416363</id> <type>INSS</type> </subject> <id>71080016</id> <type>NIHII</type> <question> <questionId>40001</questionId> <booleanResponse>true</booleanResponse> </question> </data> <questionId>1</questionId> <longResponse>11400171</longResponse>

Shibboleth : Description ( 1 / 2 ) Standards based, open source software package for web single sign-on across organizational boundaries. Attribute exchange framework Messages in SAML 1.1 Federation service Metadata in SAML 2.0

Shibboleth : Description ( 2 / 2 ) Primary Parts Identity Provider (IDP) authentication Propagation of authentication & authorization info Service Provider (SP) Management of restricted service

Shibboleth : supported partner profiles SAML (1.1) Browser / Post Attribute Push Attribute Pull WS-Federation Passive Requestor Interoperability Profile

Shibboleth : SAML Browser/POST AuthnRequest HTTP GET /SSO?shire=…&target=…&providerid=… SAML/POST HTTP POST AssertionConsumerService SAMLResponse in base64 SAMLRequest/SAMLResponse /AA SOAP AttributeQuery Protocol Back-channel  SAMLAttributeQuery  SAMLAssertion

Shibboleth : SAML Browser/POST

Shibboleth : WS-Federation Passive Requestor Interoperability Profile ADFS RequestSecurityToken HTTP GET /ADFS?wa=…&wtreply=…&wtrealm=… RequestSecurityTokenResponse HTTP POST SAMLAssertion

Shibboleth in action ( 1 / 5 )

Shibboleth in action ( 2 / 5 )

Shibboleth in action ( 3 / 5 )

Shibboleth in action ( 4 / 5 )

Shibboleth in action ( 5 / 5 )

Shibboleth : overview

Shibboleth : Steps Service Provider (SP) Installation software Shibboleth site Packages for different OS Installation instructions Configuration eHealth cookbooks setup restricted access to service Integration eHealth IDP

Shibboleth: Links Shibboleth eHealth technical library http://shibboleth.internet2.edu/ documentation Download Sources and binaries eHealth technical library https://www.ehealth.fgov.be/nl/page/website/home/platform/technicallibrary.html cookbooks

SSO @ web services

SSO general principles (1/2) Purpose Completes the "Integrated user and access management" Access to various services within a single session Main features Supports ABAC and ZBAC principles Based on SAML protocol Terminology WSC : web service consumer WSP : web service provider STS : Secure Token Service

SSO general principles (2/2)

STS Request/Response (1/7) Description of the flows (1) and (2) Illustration with the set of attributes Recognized pharmacy Recognized pharmacist Other rules will be supported in the same way Attribute or access oriented

STS Request/Response (2/7) Request general structure Header deals with 'security of the call to the STS service' x509 Identification certificate eID eHealth certificate Federal Government Example: x509:identification of the hospital

STS Request/Response (3/7) Request : SAML elements Confirmation method: Holder-of-Key Sender-Vouches Subject SAML assertion Identification Attr. Policy Attr Attribute to confirm Attributetype Example claim: recognized general practitioner claim: recognized hospital

STS Request/Response(4/7) Response general structure General characteristic global Status assertion signed by eH Response to requested claims Example claim: recognized general practitioner TRUE claim: recognized hospital

STS Request/Response (5/7) Remarks Attributes not certified Example claim: recognized pharmacy TRUE claim: recognized pharmacist FALSE Technical errors when error occurred while processing request abort request error message send to WSC REQ-01: Checks on ConfirmationMethod failed Time validity each attribute is certified for a certain period

WSC/WSP communication (1/3) Description of the flow (3) Illustration with the set of attributes Recognized hospital Recognized general practitioner

WSC/WSP communication (2/3) Request general structure Header deals with 'security of the call to the WSP service' Identification based on SAML assertion Example: SAML assertion delivered by eHealth

WSC/WSP communication (3/3) Remark Verifications to perform by the WSP Validity of x509 certificate Certificate Revocation List (CRL) Trusted Certificate Authority Check SAML assertion Signed by eHealth Assertion still valid (cfr. Time Validity) Check Holder-Of-Key profile SAML assertion & x509 and, obviously, its further access rules