Skip to main content

How to enable proxy service security in ESB 4.9.0?

Security is  one of the major concern when we developing API base integrations or application developments. WSO2 supports WS Security, WS-Policy and WS-Security Policy specifications. These specifications define a behavior model for web services. Proxy service security requirements are different from each others.
WSO2 ESB providing pre-define commonly used twenty security scenarios to choose based on the security requirements. This functionality is provided by the security management feature which is bundled by default in service management feature in ESB. This configuration can be done via the web console until ESB 4.8.1 release, but this has been removed from the ESB 4.9.0. Even though this feature isn't provided by the ESB web console itself same functionality can be achieved by the new WSO2 Dev Studio. WSO2 always motivate to use dev studio to prepare required artifacts to the ESB rather than the web console. Better way to explain this scenario is by example. Following example provides guides to the way you need to enable security for the proxy service in newly released ESB 4.9.0.
                                                                                                                                                                                
Note: Understanding the actual security requirement is the first step you need to follow before starting the implementation of the secure proxy service. In this example, I'm selecting basic auth as the security scenario.

1. As the first step, we need to create proxy service to secure. I'm going to create simple proxy service which front the SimpleStockQuate service.
  •  Create ESB config project from the Developer Studio dashboard. 
  • Create Proxy service which named SimpleProxy.

















2. We need to define security policy file to enable security for the proxy service. Registry resource project needs to create for storing policy file.

  • Create Registry resource artifact(SecurityPolicy - Resource type should be WS-Policy)
  • Select design view of the SecurityPolicy.xml file. You can see all pre-defined security scenarios listed in this view. In this example, I'm selecting UserNameToken scenario. Under this scenario, we need to select user rolls which allow to access the service. This option allow you to select rolls inline and select available rolls from the ESB.

3. Now we have both proxy service and security policy file. Next step is to enable security using defined policy file. Proxy service properties has separate section for the security. It contains two properties which required for enabling security.
  • Security Enabled – This property should be True for enabling security
  • Service Policy – You need to select defined security policy file as a value of this field.










4. Now Security configurations has been finished. Next step is to create CAR file to deploy into the ESB. We have two options to deploy artifacts into the EBS.
  • Export artifacts as a CAR file from Developer Studio and upload file to the ESB as a carbon application.
  • Configure ESB as a server inside the Developer Studio and deploy directly.












We are going to use first option in this example. Since we need to export both ESB config and registry project to the single car file, we need to add “Composite Application Project” to the Dev Studio and need to associate previous setup applications (ESB Config , Registry resource). You can export CAR file easily by selecting “Export Composite Application Project” option from the menu which pop up for the right click.


5. WO2 ESB providing very simple way to install car file by just select and upload way.
You can find this option(“Carbon Applications") in the bottom of the right-hand side menu.
When you click on the Service List menu you can see the deployed proxy service(“SimpleProxy”)
with enable security.











6. You can simple Test this proxy service by “Try this service” feature which provided by th ESB itself. You have to fill the userName and password fields before sending the request.













Likewise, you can try other predefined scenarios or your own security implementation with the custom policy.



Comments

Javi said…
Template WS-Policy doesn't exist in Developer Studio 3.7.1
You can use WSO2 Developer Studio 3.8 which is compatible with ESB 4.9.0 release to enable security in a proxy.

Popular posts from this blog

Java Source Code to Change Local IP Address

Hi guys..

Try This code to change your Local IP address.


import java.io.IOException;
import java.lang.Runtime;
public class Chang_Ip {



public static void main(String args[]) throws IOException
{

String str1="192.168.0.201";
String str2="255.255.255.0";
String[] command1 = { "netsh", "interface", "ip", "set", "address",
"name=", "Local Area Connection" ,"source=static", "addr=",str1,
"mask=", str2};
Process pp = java.lang.Runtime.getRuntime().exec(command1);

}


}

How to preserving HTTP headers in WSO2 ESB 4.9.0 ?

Preserving HTTP headers are important when executing backend services via applications/middleware. This is because most of the time certain important headers are removed or modified by the applications/middleware which run the communication. The previous version of our WSO2 ESB, version 4.8.1, only supported “server” and “user agent” header fields to preserve with, but with the new ESB 4.9.0, we’ve introduced a new new property (http.headers.preserve) for the passthru (repository/conf/passthru-http.properties) and Nhttp(repository/conf/nhttp.properties) transporters to preserve more HTTP headers.
Passthru transporter – support header fields LocationKeep-AliveContent-LengthContent-TypeDateServerUser-AgentHostNhttp transport – support headersServerUser-AgentDate
You can specify header fields which should be preserved in a comma-separated list, as shown below. http.headers.preserve = Location, Date, Server Note that properties(http.user.agent.preserve, http.server.preserve), which were used …

How Schedule failover message processor helps for the guaranteed delivery ?

Before we talk about the failover message forwarding processor, it’s better to understand the big picture of the concepts and use cases. The Scheduled Failover Message Forwarding Processor is part of the bigger picture of themessage store and message processor.

Message Store Message Processor. WSO2 ESB’s Message-stores and Message-processorsare used to store incoming messages and then deliver them to a particular backend with added Quality of Services (QoS), such as throttling and guaranteed delivery. The basic advantage of the MSMP is that it allows you to send messages reliably to a backend service. These messages can be stored in a different reliable storage such as JMS, JDBC message stores. The MSMP powered by three basic components:



1. Store Mediator.
The Store mediator is the synapse mediator and can be used to store messages in the message store.

2. Message Store.
A message store is storage in the ESB for messages. The WSO2 ESB comes with four types of message store implementations …