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

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte