View
7.323
Download
5
Category
Preview:
DESCRIPTION
Citation preview
Hasini Gunasinghe Software Engineer-WSO2
Security requirements of a SOA solution in healthcare domain.
Security patterns to accomplish them. Implementing patterns with WSO2 ESB.
Ceycare Systems
Channelling consultation Hospital Services
Medical Laboratory Services
Collaboration with medical research institutes
Patients’ data
Medical Test results
Medical statistics
Physicians’ data
Why SOA?
Expose legacy sytem components as services.
Loose coupling
Interoperability
Flexibility
Business process composition.
Why security in SOA?
Business assets exposed to outside as services to be discovered.
Should facilitates interoperability, flexibility.
Identification and authentication
Authorization
Intergrity
Privacy
Security auditing
Survivability
Non-repudiation
Source: Security in SOA-Based Healthcare System
Requirement:
Services need to identify and verify the claimed identity of internal users of the organization.
Pattern: Authentication Patterns: Direct Authentication
- Authenticating users with credentials stored internally.
- Credentials can be : - Username/password
- Username token
- X.509 certificates
Patient’s Records: Name: Age: Histroy:
Secured Proxy
Ceycare credential
store
Credential
1
2
3
Requirement: Services need to identify and verify the claimed identity of external users – from partner organizations.
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.
Scenario 1: Authentication accross organizational boundries
Secure Token Service of CeyMed
CeyMed
CeyCare
CeyMed credential
store
Patient’s Records: Name: Age: Histroy:
Secured Proxy
1
2 3
4
Requirement:
Facilitate communication between clients and services which talk in different authentication mechanisms.
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
Patient’s Records: Name: Age: Histroy:
Ceycare credential
store
Username Token
2
3
BasicAuth Header
1
Requirements: - Avoid user credentials to be passed to
backend service. - Avoid user bypassing security processing.
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.
Patient’s Records: Name: Age: Histroy:
Secured Proxy
Ceycare credential
store
User Credential
1 2
3
ESB Credential
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
Pattern: Authorization patterns Role based access control:
Assign users to roles.
Grant privileges to roles.
This is a coarse grained authorization model.
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”
Pattern: Authorization patterns Claim based authorization :
Provides fine grained authorization.
Policy based access control with XACML – provides flexibilty.
Authorization based on claims carried in SAML token.
SAML Token
Heart Patient’s Records: Name: Age: Histroy:
Secured Proxy
Entitlement Mediator (2) XACML
Authorization request
(3) Authorization decision
[PEP]
PAP, PDP, PIP
1
(4) Allow/deny access
Requirement: Delegating access:
Eg:
Application in a phisician’s mobile device needs to retrieve channelling appointments from his account in Ceycare System.
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.
Chanelling appointments Name: Time: Hospital:
OAuth Mediator
(3) Authorization grant
(4) Access Token
5
(7) Allow/ deny access
1
2
Authorization request
Authorization grant
Access request+ Access Token
(6) Validate Access Token
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.
Patterns:
Message protection patterns: Data origin authentication and intergrity -
digital signatures. Data confidentiality - digital encyption.
Example Configuration:
Example Configuration:
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.
Pattern: Boundry defense pattern Exception shielding:
- Sanitize unsafe exception data by replacing it with non-harmful exception message.
- Enrich mediator of ESB.
Example un-safe message:
Example Configuration:
Requirement:
Log security incidents to trace system abuse: - Failed login attempts - Unauthorized access attempts to services
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)
Example Configuration:
Requirement: Prevent denial of service attacks caused by replaying valid messages.
Pattern: Boundray defense pattern Replay mitigation: - Apply throttling rules at the entry point
(ESB). - Validate message freshness by WS-Security
mechanisms (Timestamp).
Applying throttling rules in ESB: Control access at three different levels through throttling: 1. Global 2. Service 3. Operation
Throttling at global level:
Throttling at service level:
Configuring throttling in ESB:
Example Time Stamp in WS-Security Header:
Requriement: Mitigate damages to the system from messages with malicious content : - SQL injection - X-Doc attacks
Pattern: Boundray defense pattern Message validation : - XML Schema validation. - Regular expression validation to avoid SQL
injections contained in strings. - Validation & Filter mediators of ESB.
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
Example Configuration:
Security requierments related to a healthcare SOA solution.
Security patterns used to accomplish them.
How WSO2 ESB fits in the security patterns.
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
https://ail.google.com/mail/u/0/?ui=2&ik=ad9ae58f41&view=att&th=1331a70983344a32&attid=0.1&disp=thd&realattid=f_gtxto6mk0&zw
Selected Customers
• QuickStart • Development
Support • Development
Services • Production
Support • Turnkey Solutions
• WSO2 Mobile Services Solution
• WSO2 FIX Gateway Solution
• WSO2 SAP Gateway Solution
Contact us: bizdev@wso2.com
Recommended