View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Security requirements of a SOA solution in healthcare domain. Security patterns to accomplish them. Implementing patterns with WSO2 ESB.
Hospital Services Channelling consultation Physicians’Patients’ data data Ceycare Systems Medical Laboratory Collaboration with medical Services research institutes Medical Test results Medical statistics
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 claimedidentity 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
Requirement:Services need to identify and verify the claimedidentity of external users – from partnerorganizations.
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 CeyCare 4 Patient’s Records:Secure Token Name: Service of Age: CeyMed Histroy: 2 Secured Proxy 3 CeyMed 1 credential store CeyMed
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
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.
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.
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.
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.
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)
Requriement:Mitigate damages to the system from messageswith 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