Embed Size (px)
DESCRIPTION
Security is a key aspect of any successful enterprise SOA solution. The Enterprise Service Bus is usually the entry point to an enterprise SOA solution. It is also the central place through which the incoming and outgoing messages flow, thus making it the most relevant location to enforce security measures of the solution. This presentation which was used in a webinar, goes through the recurring problems and requirements in the space of identity, security and access control of a SOA solution along with the security patterns that can be applied to overcome them using the WSO2 ESB as a security gateway. Use cases are taken from a Healthcare SOA solution to illustrate these challenges and the corresponding solution patterns that can be designed to overcome them.
Citation preview
Security Patterns with WSO2 ESB
Hasini GunasingheSoftware Engineer-WSO2
Outline
Security requirements of a SOA solution in healthcare domain.
Security patterns to accomplish them.
Implementing patterns with WSO2 ESB.
Example
Ceycare
Systems
Channelling consultation
Hospital Services
Medical Laboratory Services
Collaboration with medical research
institutes
Patients’ data
Medical Test
resultsMedical
statistics
Physicians’ data
Example
Why SOA?
Expose legacy sytem components as services.
Loose coupling Interoperability Flexibility Business process composition.
Example
Why security in SOA?
Business assets exposed to outside as services to be discovered.
Should facilitates interoperability, flexibility.
Security Requirements
Identification and authentication Authorization Intergrity Privacy Security auditing Survivability Non-repudiation
Source: Security in SOA-Based
Healthcare System
Identification & authentication
Requirement:
Services need to identify and verify the claimed identity of internal users of the organization.
Identification & authentication
Pattern:
Authentication Patterns:
Direct Authentication- Authenticating users with credentials stored
internally.
- Credentials can be :- Username/password- Username token- X.509 certificates
Direct Authentication
Patient’s Records:Name:Age:Histroy:
Secured Proxy
Ceycarecredential store
Credential
1
2
3
Identification & authentication
Requirement:
Services need to identify and verify the claimed identity of external users – from partner organizations.
Identification & authentication
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.
Brokered Authentication
Scenario 1: Authentication accross organizational boundries
Secure Token
Service of CeyMed
CeyMed
CeyCare
CeyMedcredential store
Patient’s Records:Name:Age:Histroy:
Secured Proxy
1
23
4
Identification & authentication
Requirement:
Facilitate communication between clients and services which talk in different authentication mechanisms.
Identification & authentication
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
Protocol Transition
Patient’s Records:Name:Age:Histroy:
Ceycarecredential store
Username Token
2
3
BasicAuth
Header
1
Identification & authentication
Requirements:
- Avoid user credentials to be passed to backend service.
- Avoid user bypassing security processing.
Identification & authentication
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.
Trusted sub system pattern
Patient’s Records:Name:Age:Histroy:
Secured Proxy
Ceycarecredential store
UserCredenti
al
12
3
ESBCredenti
al
Authorization
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
Authorization
Pattern:
Authorization patterns Role based access control:
Assign users to roles. Grant privileges to roles. This is a coarse grained authorization
model.
Authorization
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”
Authorization
Pattern:
Authorization patterns Claim based authorization :
Provides fine grained authorization. Policy based access control with XACML
– provides flexibilty.
Claim based authorizationAuthorization based on claims carried in SAML token.
SAML Toke
n
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
Authorization
Requirement:
Delegating access:Eg:Application in a phisician’s mobile device needs to retrieve channelling appointments from his account in Ceycare System.
Authorization
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.
Constrained access delegation
Chanelling appointmentsName:Time:Hospital:
OAuthMediato
r
(3) Authorization grant
(4) Access Token
5
(7) Allow/deny access
1
2
Authorizationrequest
Authorizationgrant
Access request+ Access Token
(6) Validate Access Token
Intergrity & Privacy
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.
Intergrity & Privacy
Patterns:
Message protection patterns: Data origin authentication and
intergrity - digital signatures. Data confidentiality - digital
encyption.
Message protection patternExample Configuration:
Message protection patternExample Configuration:
Intergrity & Privacy
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.
Intergrity & Privacy
Pattern:
Boundry defense pattern Exception shielding:
- Sanitize unsafe exception data by replacing it with non-harmful exception message.
- Enrich mediator of ESB.
Exception Shielding
Example un-safe message:
Exception Shielding
Example Configuration:
Security Auditing
Requirement:
Log security incidents to trace system abuse:- Failed login attempts - Unauthorized access attempts to
services
Security Auditing
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)
Audit Intercepter
Example Configuration:
Survivability
Requirement:
Prevent denial of service attacks caused by replaying valid messages.
Survivability
Pattern:
Boundray defense pattern Replay mitigation:- Apply throttling rules at the entry
point (ESB).- Validate message freshness by WS-
Security mechanisms (Timestamp).
Replay mitigation
Applying throttling rules in ESB:
Control access at three different levels through throttling:1. Global2. Service3. Operation
Replay mitigation
Throttling at global level:
Replay mitigation
Throttling at service level:
Replay mitigation
Configuring throttling in ESB:
Replay mitigation
Example Time Stamp in WS-Security Header:
Survivability
Requriement:
Mitigate damages to the system from messages with malicious content :- SQL injection - X-Doc attacks
Survivability
Pattern:
Boundray defense pattern Message validation :- XML Schema validation.- Regular expression validation to
avoid SQL injections contained in strings.
- Validation & Filter mediators of ESB.
Message Screening/Validation
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
Message Screening/Validation
Example Configuration:
Today we discussed ...
Security requierments related to a healthcare SOA solution.
Security patterns used to accomplish them.
How WSO2 ESB fits in the security patterns.
References:
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
Q & A
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
WSO2 engagement model• QuickStart• Development
Support• Development
Services• Production
Support• Turnkey Solutions• WSO2 Mobile Services Solution
• WSO2 FIX Gateway Solution
• WSO2 SAP Gateway Solution
