I have a lot of proxies in WSO2 ESB that I have to securize. I need them to be securized using Username Token when deploy, instead of browsing to the dashboard and enabling it one by one.
Any help?
I guess currently, you need to use management console and do it. From the UI, it is calling a backend web service. You can automate process by automating this backend web service. This web service is exposed by following component [1]. You can use soapui or some client program to automate this web service.
[1] http://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/security/org.wso2.carbon.security.mgt/
I had similar requirement, here is how I solved it
Apply Role security to WSO2 ESB Proxy using Java API
Also you can find the test case here on how to use the methods
http://svn.wso2.org/repos/wso2/tags/carbon/3.2.3/products/bps/2.1.1/modules/integration/org.wso2.bps.management.test/src/test/java/org/wso2/bps/management/SecurityTest.java
Well here how the code snippet goes to secure any proxy service with default security scenarios of WSO2 ESB. In WSO2 ESB "scenario1" signifies Usernametoken based security. Now if you wish to secure your proxy with scenario1 follow the below code snippet:
public void applySecurityOnService(String serviceName, String policyId,
String[] userGroups, String[] trustedKeyStoreArray,
String privateStore)
throws SecurityAdminServiceSecurityConfigExceptionException,
RemoteException {
ApplySecurity applySecurity;
applySecurity = new ApplySecurity();
applySecurity.setServiceName(serviceName);
applySecurity.setPolicyId("scenario" + policyId); //scenario1 i.e. for Usernametoken security policyId should be 1
applySecurity.setTrustedStores(trustedKeyStoreArray);
applySecurity.setPrivateStore(privateStore);
applySecurity.setUserGroupNames(userGroups);
stub.applySecurity(applySecurity);
_logger.info("Security Applied Successfully");
}
Here is how you may call this method from your client class:
applySecurityOnService("MyProxy", "1", new String[]{"TestRole"}, new String[]{"wso2carbon.jks"}, "wso2carbon.jks");
Related
i have a question about an architectural solution feasibility using WSO2.
This is my scenario:
I have a Web Service REST exposing some functionalities
I have the WSO2 ESB
I have a client layer (Liferay)
the architecture i want to develop is the one showed in the first image:
http://s11.postimg.org/gu6b6k3zn/Immagine.png
1) Liferay clients send request to avail one functionality
2) WSO2 ESB (clustered) get the client request... and (as a proxy) redirects it to che tomcat server by using load balancing mechanism
3) Web service on tomcat receives the request and answers to it
Studying the WSO2 documentation i saw the configuration showed in the img 2 dealing with esb clustering and load balancing
http://s17.postimg.org/tuy885gzz/Immagine2.png
As i can see, in this case the Tomcat Application Server(inside WSO2 AS) is embedded inside the WSO2 ESB, so i have to deploy my REST WS into the WSO2 esb, and then clustering it.
I want to ask if the second solution is the only permitted or if i can obtain my first architectural solution in which the tomcat instances are decoupled from the ESB instances on a third (physically separated) layer.
In image 2, (http://s17.postimg.org/tuy885gzz/Immagine2.png), it is shown a Fail over scenario, where when the Primary ESB node goes down, the requests will be routed to backup node 2.
Even if you want to deploy something like in image 2, you can have the WSO2 AS layer sitting behind the ESB server layer. There you can deploy your REST WS. The REST WS can be fronted by a proxy in your ESB. And the proxy can be accessed by your life ray client.
I have done a few use cases on WSO2-ESB including protocol mediation with transformation and service-chaining.
In all of them I had to manually write the wsdl for the proxy service. Having experienced other vendor products including Oracle and Tibco where wsdl generation is done by the tool.
Would it be right to assume in WSO2 ESB one needs to manually write the wsdl file to expose a proxy service on any protocol, do not see any documents calling that out.
Considering the usage of wsdl in practical use cases.
I have seen posts stating "you can give the WSDL available at your Axis2 service" but most of real time use cases would not be pass through and have custom request and response.
Thanks,
Wajid
I'm also confused with manual wsdl creation. As far as I can see there are gaps in wsdl proxy description. When I do wsdl proxy with WSO2 I have to indicate wsdl to expose
its either as:
"none" and I have only mediate function exposed
"same contract" and this breaks the whole idea of proxy because after that clients read original wsdl and go straight to original server access point.
or and I have several options to make my own wsdl.
With rich SOAP API (hundreds of methods) none of above work well, considering that manual support of exposed WSDL is rather cumbersome.
I wonder if there is more adequate way for proxying WSDL?
You can use java2wsdl generator tool to achieve the WSDL generation.
For the proxies, if you try to restrict access for some operations in your backend service, you can attach customized wsdl to the proxy.
The customization has to be done by yourself and it is simple..
If you want to generate a wsdl fro your service, jsut deploy the service in wso2as, and check the service dashboard, wsdl option to view the wsdls.
I am trying to programmatically retrieve the meta data of the end points configured to WSO2 ESB (Eg: ServiceName, WebMethods, Input/Output Parameters with Return types etc). Can someone direct me to some way/docs which could help me fetch this data.
Unfortunately it's not really clear what you want to do. Here some examples how to access properties (Meta-Data?)
inside a proxy/sequence access properties:
<property name="some name" expression="get-property('registry','conf:resource/path')"/>
<property name="some name" expression="get-property('registry',gov:resource/path')"/>
<property name="some name" expression="get-property('registry','resourceName')"/>
Or inside a Custom Mediator:
String property = (String)messageContext.getProperty("nameOfThePropery");
Or inside a Custom Mediator (getting the filename from the Transport Layer):
org.apache.axis2.context.MessageContext axis2messageContext = ((Axis2MessageContext) messageContext).getAxis2MessageContext();
// print the filename of the current transport
myLog.info("FileName: " + axis2messageContext.getTransportIn().getName());
Hope this helps you a little bit further, otherwise improve you question.
To further improve on Abdul's question, we are developing a web-service gateway between a legacy client on side and on the other side are external web-services. We have created a template/sequences in WSo2 where we trap the legacy client request and redirect it to the correct web-service based on a internal protocol.
The external web services are registered in WSo2 as endpoints. So far we have been configuring these endpoints manually using the admin console. We are looking at automating this step so that our gateway will hit WSo2 and provide the WSDL URL. A class mediator would then invoke the WSo2 / Synapse APIs to save this endpoint in the Synapse configuration. We have not been successful in this.
We have also read the docs which say that changing synapse config thru mediator is not recommended, hence would like to see if there are other options that would do this job for us.
One workaround would be to create those endpoints from the client side itself. This can be done by calling the AdminService APIs exposed by the carbon framework. In carbon, a front end of any carbon component talks to its back end through Admin Services. For example, if we take endpoints related functionalities, when you use the management console to create/delete or to do any functionalities, it would in turn call the respective back end via the "EndPointAdmin" admin service. Therefore I believe, if you want to programmatically create those endpoints, you can call the EndPointAdmin backend admin service (via EndPointAdminStub - it is the client stub corresponding to the aforesaid back end service) directly from your client side and get your requirement fulfilled.
Regards,
Prabath
I have two servlets that access two corresponding Axis2 web services on the same host. One of the servlets is read-only, while the other writes to a database.
Each of the Axis2 web services uses BASIC authentication. The read-only web service uses a system account, while the write web service uses the user's credentials (which are submitted as part of a web form).
The problem I'm running into is that the servlet called second always fails authentication to its web service. For example, I can query the read-only service through it's servlet all I want, but I get a "401: Authorization Required" when I try to use the write service. If I call the write service first, I get the same error when I try to use the read-only service.
Here is how I am setting the credentials for the connections in the servlets:
Stub service = new Stub(serviceUrl);
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
auth.setUsername(username);
auth.setPassword(password);
auth.setPreemptiveAuthentication(true);
service._getServiceClient().getOptions().setProperty(HTTPConstants.AUTHENTICATE, auth);
The servlet that accesses the read-only service has this code in it's constructor. The servlet that accesses the write service has this code in it's doGet/doPost method.
It seems that the credentials for the first service called are getting cached somewhere, but I can't find where that could be. I saw a possible solution here, but I can't find where WSClientConstants.CACHED_HTTP_STATE is defined. The comments in this JIRA issue seems to imply that it's part of org.apache.axis2.transport.http.HTTPConstants but it's not there.
Specifics:
Axis version: 1.5.1
Tomcat Version: 6.0.26
Java version: 1.6.0_23
It turns out the connections to the two different services were using the same JSESSIONID. Thus, the connection to the second web service was trying to use a session authenticated for the first web service, causing the error.
My solution for this was to define an HttpClient for each service, done by the following
MultiThreadedHttpConnectionManager manager = new MuliThreadedHttpConnectionManager();
HttpClient client = new HttpClient(manager);
ConfigurationContext context = ConfigurationContextFactory.createDefaultConfigurationContext();
context.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, client);
context.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, true);
Stub service = new Stub(context, serviceUrl);
This allows both servlets to have a separate session for their corresponding services.
The important point is to create a dedicated ConfigurationContext.
I've solved in a simpler way using a default config context when creating the stub without the multithreaded connection factory
stub = new MyStub(ConfigurationContextFactory.createDefaultConfigurationContext(), myServicesUrl);
I have created a service (Products) which accepts a ProductID value and returns data. I have SOAP and HTTP requests and responses for this service. I can access this by doing something like h**p://localhost:9763/services/Products.HTTPEndpoint/ProductID/123456 to return data.
How can I do the same thing but go through the ESB? I've tried to set up a simple pass through proxy, but when I use the "TryIt" I only get "mediate" as a option.
Any ideas?
Thanks,
Jared
You should use an appropriate WDSDL as the publish WSDL of the proxy service to 'tryit' the proxy service.
So what you can do is, get the WSDL of the actual data service and use that as the publish wsdl of the proxy. Then you can use tryit to invoke the DS.
I ended up being able to do this:
WSO2 Data Services Server service:
http://localhost:9763/services/Products
WSO2 ESB Endpoint:
Name: epProducts
Address: http://localhost:9763/services/Products.HTTPEndpoint
Format: GET
WSO2 ESB Proxy Service:
Service Name: ProductsProxy
Publishing WSDL: None
Define In Sequence: None
Define Endpoint: epProducts
Define Out Sequence: None
Define Fault Sequence: None
Send a GET request to:
http://localhost:9763/services/Products.HTTPEndpoint/ProductID/123456