2. Security requirements of a SOA solution in
healthcare domain.
Security patterns to accomplish them.
Implementing patterns with WSO2 ESB.
3. Hospital Services Channelling consultation
Physicians’
Patients’ data data
Ceycare
Systems
Medical Laboratory Collaboration with medical
Services research institutes
Medical Test
results
Medical
statistics
4. Why SOA?
Expose legacy sytem components as services.
Loose coupling
Interoperability
Flexibility
Business process composition.
5. Why security in SOA?
Business assets exposed to outside as services to
be discovered.
Should facilitates interoperability, flexibility.
6. Identification and authentication
Authorization
Intergrity
Privacy
Security auditing
Survivability
Non-repudiation
Source: Security in SOA-Based Healthcare System
10. Requirement:
Services need to identify and verify the claimed
identity of external users – from partner
organizations.
11. Pattern:
Authentication Patterns:
Brokered Authentication
Authenticating users outside the organization boundary.
Ceycare trusts a token issued by a trusted party in partner
organization.
Brokered authentication based on WS-Trust with SAML.
12. Scenario 1: Authentication accross organizational boundries
CeyCare 4 Patient’s
Records:
Secure Token Name:
Service of Age:
CeyMed Histroy:
2 Secured Proxy
3
CeyMed 1
credential
store
CeyMed
14. Pattern:
Resource Access Patterns:
Protocol Transition
ESB authenticates clients with the auth mechanism
that they understand – eg: UT
Transform credentials in the form that service
understands - eg: Basic Auth
16. Requirements:
- Avoid user credentials to be passed to
backend service.
- Avoid user bypassing security processing.
17. Pattern:
Resource Access Patterns:
Trusted sub system pattern
User authenticates to ESB with his/her credentials.
BE service trusts ESB.
ESB accesses BE service on behalf of authenticated user.
18. Patient’s
Records:
Name:
ESB Age:
Credential Histroy:
3
User
Credential
Secured Proxy
1
2
Ceycare
credential
store
19. Requirement:
Control access based on privileges of the users.
Eg:
Users in role: ‘Physician’ can update patients’ records
while users in role: ‘Lab technologist’ can only view
records
20. Pattern:
Authorization patterns
Role based access control:
Assign users to roles.
Grant privileges to roles.
This is a coarse grained authorization model.
21. Requirement:
Control access based on user’s claims, in a fine
grained manner.
Eg:
Heart patients data could only be accessed by
Physicians with job title: “Cardiologists”
22. Pattern:
Authorization patterns
Claim based authorization :
Provides fine grained authorization.
Policy based access control with XACML –
provides flexibilty.
24. Requirement:
Delegating access:
Eg:
Application in a phisician’s mobile device needs to
retrieve channelling appointments from his account
in Ceycare System.
25. Pattern:
Authorization patterns
Constrained delegation using OAuth:
1. Mobile app authenticates to authorization server.
2. Mobile app requests authorization from resource owner.
3. Resource owner authenticates to authorization server.
4. Resource owner grants permissions to the application to
access resource on behalf of him.
5. Application obtains access token from access grant.
6. Resource server (ESB) validates access token.
7. Allow/Deny access to BE resource.
27. Requirements:
Protect sensitive personal data during
transmission from :
tampering
unauthorized access
Non-repudiation - A patient’s account should
show who has updated his/her medical
records.
31. Requirement:
Avoid exposing sensitive data through exceptions.
Legacy application code might throw exceptions
containing sensitive information.
Need to filter those expections when system is exposed
to external parties.
32. Pattern:
Boundry defense pattern
Exception shielding:
- Sanitize unsafe exception data by replacing it with
non-harmful exception message.
- Enrich mediator of ESB.
36. Pattern:
Boundry defense pattern:
Audit Intercepter
All messages flow through the a gateway of the
system. (ESB)
Necessary auditing is done by the logging at the
gateway. (Log mediators of ESB)
46. Pattern:
Boundray defense pattern
Message validation :
- XML Schema validation.
- Regular expression validation to avoid SQL
injections contained in strings.
- Validation & Filter mediators of ESB.
47. Examlpe SQL Injection attack:
Query:
SELECT * FROM p r e s c r i p t i o n s WHERE pat i ent ID = ' + $pat i ent ID +' ;
If
$pat i ent ID = 3 5 2 1 ' ; DROP TABLE p a t i e n t s ;
Resulting query causing SQL injection:
SELECT FROM p r e s c r i p t i o n s WHERE pat i ent ID = ' 3 5 2 1 ' ;
DROP TABLE p a t i e n t s ;
Source: Security in SOA-Based Healthcare System
49. Security requierments related to a healthcare
SOA solution.
Security patterns used to accomplish them.
How WSO2 ESB fits in the security patterns.
50. WSO2 Security & Identity Gateway solution
white paper:
http://wso2.com/casestudies/wso2-security-and-
identity-gateway-solution/
Security in SOA based healthcare systems:
By Richard Sassoon
53. • QuickStart
• Development
Support
• Development
Services
• Production
Support
• Turnkey Solutions
• WSO2 Mobile Services Solution
• WSO2 FIX Gateway Solution
• WSO2 SAP Gateway Solution