security patterns with wso2 esb

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

Thank you...!!!

Contact us: bizdev@wso2.com