Skip to main content

How to secure your SOA system with WSO2 ESB - Security patterns tutorial

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
  • Authorization
  • Integrity
  • Privacy
  • Security auditing
  • Availability
  • Non-repudiation

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
  • username/password
  • 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.



  • Access delegation
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.

  1. Authorization request
  2. Authorization grant by the user
  3. Using authorization grant to get the token from authorization server
  4. Get the token from server
  5. Using the token to access the resource
  6. ESB validate the token with authorization server
  7. 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.

  • Digital Signatures 
This would make sure that the origin of the message is an authorized entity. This will keep intruders away from changing the message.

  • Digital encryption
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.


Survivability (Availability)

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. 

Cheers !!!




Comments

  1. Nice and good article. It is very useful for me to learn and understand easily. Thanks for sharing your valuable information and time. Please keep updatingmulesoft online training

    ReplyDelete

Post a Comment

Popular posts from this blog

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...

WSO2 ESB usage of get-property function

What are Properties? WSO2 has a huge set of mediators but property mediator is mostly used mediator for writing any proxy service or API. Property mediator is used to store any value or xml fragment temporarily during life cycle of a thread for any service or API. We can compare “Property” mediator with “Variable” in any other traditional programming languages (Like: C, C++, Java, .Net etc). There are few properties those are used/maintained by ESB itself and on the other hand few properties can be defined by users (programmers). In other words, we can say that properties can be define in below 2 categories: ESB Defined Properties User Defined Properties. These properties can be stored/defined in different scopes, like: Transport Synapse or Default Axis2 Registry System Operation Generally, these properties are read by get-properties() function. This function can be invoked with below 2 variations. get-property(String propertyName) get-property(String scop...