1. Integrated User and Access Management1

2. General Principles

3. 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)

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

5. 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?

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

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

8. Policy Enforcement Model ( 7 / 8 )

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

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

11. 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 Bruxelles
subject: eHealth – identification certificate proxy
Fax: 02/ (Barbara Meyers / Sara Vander Meeren)

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

13. web

14. Access to application: principle ( 1 / 3 )

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

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

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

18. Access to an application : example ( 2 / 4 )

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

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

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

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

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

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

25. Shibboleth : SAML Browser/POST

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

27. Shibboleth in action ( 1 / 5 )

28. Shibboleth in action ( 2 / 5 )

29. Shibboleth in action ( 3 / 5 )

30. Shibboleth in action ( 4 / 5 )

31. Shibboleth in action ( 5 / 5 )

32. Shibboleth : overview

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

34. Shibboleth: Links Shibboleth eHealth technical library
documentation
Download Sources and binaries
eHealth technical library
cookbooks

35. web services

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

37. SSO general principles (2/2)

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

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

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

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

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

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

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

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