Security is one of the critical features of any SOA system. All of your enterprise is depend on the security mechanisms applied in your environment. People always think about computer security is some magic under the hood and most people cannot understand it’s behavior. But in reality computer security is a well designed system which involves different parties. In this blog post I will be discussing about security aspects of any SOA system and some heavily used security patterns applied to cover those aspects.
In any SOA system there can be one or more security patterns applied at different points of the service implementation. Here is a list of features we need to cover through proper designing of security patterns.
- Identification and Authentication
- Security auditing
Identification and Authentication (Who you are)
System needs to identify and verify the claimed identity of users of your system. Users can be internal users or external users. If the users are internal, then users can be stored in an internal system (database or LDAP). In this case we can use Direct Authentication with one of the following mechanisms.
- username token
- x.509 certificates
If the system accessed by external users, then we need to get help from a third party to validate identity of the users. Brokered Authentication can be used to authenticate users from external organizations.
Another important use case in authentication is that different systems may authenticate with different security mechanisms. In that kind of scenario, we need to transform the security mechanisms to connect the systems. We can use the Protocol Transition pattern in this kind of use case as depicted below. In this scenario, users are authenticated with UsernameToken(UT) mechanism but the actual BE service is expecting BasicAuth mechanism. We can use WSO2 ESB to transform the protocols.
In another scenario, user credentials would not need to be passed to the BE service due to some security concerns (Ex:Banking credentials). In this kind of situation, users needs to be validated in the ESB but the user credentials should not be passed to the service. This can be achieved through the Trusted Sub System pattern as depicted in below diagram.
Authorization (What you can do)
In an enterprise system, it is not enough to identify who you are but it needs to make sure that you have the access to only things you have authorized to. Authorization is one of the major security feature that any critical system would facilitate. Authorization can be achieved in fine grained manner and coarse grained manner as mentioned below.
- Role based authorization (Coarse grained access)
Users are assigned to specific roles and roles are granted for specific permissions. Every user should have one or more roles.
- Claim based authorization
Policy based access control using XACML (eXtensible Access Control Markup Language) policies. This provides coarse grained access to the services.
Another important mechanism in providing authorization is delegating access on behalf of a user to another system or user. As an example, mobile application may need to access your gmail account to display your emails in your mobile phone. In this kind of scenario, user needs to delegate his access privileges to mobile application in trust worthy manner. This can be achieved through OAuth protocol.
The above flow can be described as below.
- Authorization request
- Authorization grant by the user
- Using authorization grant to get the token from authorization server
- Get the token from server
- Using the token to access the resource
- ESB validate the token with authorization server
- Allow or deny access
Integrity and Privacy (Make sure data is not changed or accessed during transmission)
Another important aspect of an enterprise system is the integrity of the data and the privacy. Data may be flowing through different networks and different channels. During this communication, there is a high risk of changing/tampering or accessing data by unauthorized users. To overcome this kind of challenge we need to make sure messages are communicated through secure channels. We can use message protection patterns to save the integrity of the messages.
This would make sure that the origin of the message is an authorized entity. This will keep intruders away from changing the message.
By using encryption, we can achieve the confidentiality of the message.
- Avoid sensitive data through exceptions
Sometimes legacy applications may throw exceptions which includes some sensitive data that should not be exposed. In this kind of scenarios, your system should filter out these exceptions before sending errors to the third party applications. We can use Boundary Defense Pattern to overcome this kind of situations.
Exception Shielding: We can use enrich mediator of the ESB to replace the sensitive information with custom error messages in ESB.
Security Auditing (Who has accessed the system)
Even though we apply different access control mechanisms in the system, there can be users who abuse the policies of your enterprise. In that kind of scenarios, it is essential to have an auditing system to check the users who accessed each and every resource. As an example, you should be able to see
- Failed login attempts
- Unauthorized access attempts
We can use the Boundary defense pattern Audit Interceptor inside the ESB to log each and every request to the system. We can use WSO2 ESB log mediator to have audit information.
Intruders will try every possible method to hack in to your system. Another method they used to break your system is Denial Of Service (DOS) attacks. Therefore, your enterprise system should be able to survive from such attacks and keep the availability of the system. We can use Boundary defense pattern Replay Mitigation to overcome such attacks. You can use the following methods to overcome such DOS attacks.
- Apply throttling rules to the entry point
We can apply throttling rules at several different levels in WSO2 ESB. You can apply throttling at Global level, Service level or Operation level inside ESB.
- Validate message freshness with WS-Security mechanisms like Timestamp
- Mitigate damages to the system from messages with malicious content
Sometimes users may send some malicious content inside messages to break your system. SQL injection and X-Doc attacks are common attacks that hackers use to compromise your system. We can overcome this kind of attacks with Message validation mechanisms.
We can use Validate mediator in WSO2 ESB to validate a message against a particular schema.
We can use filter mediator of WSO2 ESB to filter the content of the messages before going through to the system.
As I mentioned in the beginning of the post, Security is not hard to understand but it is lengthy and you need to give attention to every detail of your system. But ultimately that would get paid off big time when you prevent your system from intruders or hackers.