Integrating any WSO2 product to the LDAP user store of WSO2 Identity Server

 

Integrating to an external user-store is a feature that is available in the carbon kernel hence all WSO2 products has this feature available. However most of the product distributions are shipped with the product been integrated to a JDBC user-store which is linked to the inbuilt H2 DB.

WSO2 Identity Server which is the Identity and Access Management product of WSO2 has an in-built LDAP user-store. It is possible to integrate any other WSO2 product to this internal LDAP user store of the Identity Server to carry out testing on any cross product scenarios where the user-store needs to be shared with each other. Let’s see how this can be done.

 

In order to get this working you will need a WSO2 Identity Server product. In this case we are using the latest Identity Server version available (5.1.0). We will also need another WSO2 product that needs to integrate to the LDAP of the Identity Server, in this case we will choose WSO2 API Manager (1.10). First of all open the following user-mgt.xml file in the API Manager configuration which can be found in the following location.

<API_Manager_Home>\repository\conf\user-mgt.xml

 

Inside this configuration file you would see the user-store configuration relating to the product. The default product distribution is integrated to the inbuilt H2 Database through the JDBCUserStoreManager. Let’s comment this configuration. Now add the below configuration that would provide details on the remote LDAP instances hosted inside the WSO2 Identity Server. Note that we are setting ‘ConnectionURL’ assuming that the Identity Server runs on localhost.

 

 

In this case we are integrating the API Manager so that it can both read and write from the user-store, it is possible to configure the instance to only read from the external user-store in such a case change the class name to ‘org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager’.

 

Start the Identity Server first and then the secondary WSO2 product (in this case the WSO2 API Manager). You can now see that users which resides in the WSO2 Identity Server is shared with the WSO2 API Manager instance.

 

 

 

XACML Reference Architecture based on WSO2 Identity Server

XACML is a powerful access control policy language implemented in XML that can provide a standardized way of validating authorization requests. XACML is the de-facto standard for authorization and provides the ability for a 3rd party application/component to enforce attribute based access control.

Given below is a reference architecture on how different XACML components can work in the deployment.

Xacml

Policy Enforcement Point (PEP) – PEP is a component that would enforce access control to a resource based on the input received from a Policy Decision Point (PDP). In the actual deployment PEP can be an application that would provide access to a resource. PEP would send attributes to the PDP and the PDP would reply back with response that would be either to allow or deny access to a resource.

Policy Decision Point (PDP) – PDP is the XACML engine that makes policy decisions on behalf of an enforcement point. PDP would make policy decisions based on a set of XACML polices that are deployed in the PDP.

Policy Information Point (PIP) –  PIP is an information source to which PDP can refer to and get more information on an attribute. PIP can be a user store, a flat file, a DB or any data source. For example if the PDP receives a username as an attribute, it can refer to a user store and get the set of roles assigned to that particular role to make a decision on whether to deny or grant access to a resource.

Policy Administration Point (PAP) – PAP is a component from which XACML policies are created/uploaded, edited and deployed to a PDP. An authorized user can come and create these policies in the PAP and the required policies can be deployed to the PDP.

Policy Repository – Policy Repository is where all the XACML policies are stored, policy repository can also manage multiple versions of a XACML policy.

Throttling of API’s using WSO2 API Manager

When exposing API’s for consumption it is of paramount importance that the API access is controlled so that service consumers are not able to misuse these exposed API’s. WSO2 API Manager provides the capability to throttle API’s that are exposed via the API Manager. API Manager allows throttling at multiple levels.

1. Application Level throttling
2. API Level throttling
3. Resource level throttling

To understand the above levels of throttling we need to first understand the concept of API’s and applications in the API Manager.

An application inside the WSO2 API Manager is a logical group to which API’s are subscribed into. For example if you take a Weather Application, this will have 2 API calls. First one would make a call to a Location API to get GPS coordinates of the current location, after which a second API call would be made to a Weather API to get weather information of the current coordinates.So in this case the Application within the API Manager would be the ‘Weather Application’ and both the Location API and the Weather API would be subscribed under this application. This can be illustrated in the diagram below

IMG1_temp
Lets related the above diagram to different throttling tiers that are available with the API Manager, this can be illustrated as below.

IMG1_temp

1. Application Level Throttling

Each application can have a throttling policy defined that would limit the aggregated number of API calls that can be made to API’s subscribed under that application. In this case we can throttle the number of API calls made from the weather application irrespective of whether they are calling the Location or the Weather API. A throttling tier can be associated to an application from API Store. This can be done by navigating to ‘My application’ tab as shown below.

appView

2. API Level Throttling
Each API can be associated with a throttling tier. When an API is subscribed the subscriber would have a choice to choose which throttling plan to subscribe. This is shown in the screenshot below

APIView

The choice of throttling plans that needs to be associated to an API can be selected at the point of API creation. Given below is a screenshot which shows how to add a throttling plan to an API.

Tiers

3. Resource Level Throttling
WSO2 API Manager also allows you to define throttling tiers for each resource within an API. This allows you to have more control on how each resource is throttled in a given API. In the above example the Weather API would have two resources ‘getWeather’ and ‘getFullWeather’ which can have two different throttling tiers. A throttling tier can be associated to a resource at the point of API creation. This is shown in the screenshot below.

resource

If you wondering on how to set these tiers that you see on the screen, you can refer to the following API Manager documentation [1]

[1] https://docs.wso2.com/display/AM190/Adding+New+Throttling+Tiers

SSL Mutual Authentication with WSO2 ESB

SSL Mutual authentication is a widely used authentication mechanism in B2B communication. This blog looks at the concept of SSL mutual authentication and how WSO2 ESB can support SSL Mutual authentication.

How mutual authentication works can be depicted in the diagram below

mutualAuth

1. Client Request a resource from the server

2. Server presents the certificate

3. Client validates the certificate from the trust-store

4. Client present its certificate to the server

5. Server validates the certificate with the trust-store

6. Client access the protected resource

For this example we are using the mutual authentication client developed by Asela, and we will be creating our own KeyStore and a TrustStore (we will be using a single key store as both the KeyStore and the TrustStore) for the client service.

1. Lets start by modify the following {ESB_home}/repository/conf/axis2/axis2.xml file by un-commenting the following line in the ‘PassThroughHttpSSLListener’ transport receiver.

<parameter name="SSLVerifyClient">require</parameter>

2. Lets create the KeyStore for the client. We will be using the Java Keytool library for this. We will be executing the following command to create the keystore.

keytool -genkey -alias Client -keyalg RSA -keystore clientKeyStore.jks -keysize 2048

Keytool will prompt the user to enter a keystore password and other values pertaining to the keystore, enter these values and create the keystore. If you go to the folder from which you executed this command you will see the newly created keystore.

3. Next lets export a public certificate from the client Keystore that we can share with the ESB. To do this lets execute the following command.

keytool -export -keystore clientKeyStore.jks -alias Client -file client.crt

You will be prompted to enter the keystore password, enter the password you entered in the step1 .You will now see the client.crt file been created in the folder

4. We will be using the default WSO2Carbon keystore in the ESB, so lets create a public certificate from the wso2carbon keystore to be shared with the client. To do this execute the command below from the following location {ESB_Home}\repository\resources\security

keytool -export -keystore wso2carbon.jks -alias wso2carbon -file ESB.crt

You will prompted to enter the password of the keystore, enter ‘wso2carbon’ which is the default password.

5. Lets now import the certificates to each other’s trust store. Since we are using the same store as the keystore and the truststore for the client lets import the ESB certificate by executing the below command. (this command assume that both the client keystore and the ESB’s public certificate in the same folder)

keytool -import -keystore clientKeyStore.jks -alias wso2carbon -file ESB.crt

You will need to enter the client keystore password you entered in step1. You will also need to confirm the importing of the certificate to the keystore

6. Lets now import the clients certificate to the ESB. To do this execute the following command.

keytool -import -keystore client-truststore.jks -alias Client -file client.crt

As before you will need to enter the client-truststore password which is ‘wso2carbon’ and you would be prompted to add the certificate to the keystore. Once you approve the addition, the certificate would be added to the keystore.

7. Now lets invoke the MutualSSL client[1], for this client to work as we have configure the keystore name, the keystore password which we have set in step1, and the client keystore location. You will also need to provide the service URL of the secured service in the ESB.  Once this is set build the MutualSSLClient using maven. After the build is complete you will see the relevant jar file in the target folder. You can run this jar file from the WSO2 Application Server by following the information here [2]. You can use the try it client in WSO2 Application Server or a SOAP client to test the MutualSSLAuthentication client.

You would see the response from the service in the client

[1] https://svn.wso2.org/repos/wso2/people/asela/ssl/MutualAuthenticationClient/

[2] https://docs.wso2.com/display/AS521/Jar+Services

How to retrieve token information using REST API in WSO2 API Manager

WSO2 API Manager provides a host of REST API’s that are capable of performing many operations in the API Manager. Given below are the steps to follow to retrieve token information such as the Consumer Key,Consumer Secret, and Access Token using the REST API. In order to perform this we assume that an instance of the API Manager is running(in port offset 0) and an application is already available in the API Store.

1. Initially you need to login to the API Store and create a cookie that can be used in subsequent REST calls. Login to the store using the following command. Replace the username and the password with the relavent value

curl -X POST -c cookies http://localhost:9763/store/site/blocks/user/login/ajax/login.jag -d "action=login&username=xxxx&password=xxxx"

2. Call the Generate Application Key API that would generate the required access keys. Use the below command to generate the application keys. The following command would generate keys for the default applications. Change the parameters accordingly based on your application.

curl -X POST -b cookies http://localhost:9763/store/site/blocks/subscription/subscription-add/ajax/subscription-add.jag -d "action=generateApplicationKey&application=DefaultApplication&keytype=PRODUCTION&provider=&tier=&version=&callbackUrl=&authorizedDomains="

Secure, Expose and Manage a SOAP Service using WSO2 API Manager and WSO2 ESB.

WSO2 API Manager provides support for both REST and SOAP based web services. However the API Manager doesn’t support WS Standards. The API Manager and the WSO2 ESB can be used in conjunction to support WS Standards to API’s exposed via the API Manager. In this blog we look at how WSO2 API Manager can be used with the WSO2 ESB to secure and expose a SOAP based API.

Given below is a diagram depicting the message flow on how WS-Security is implemented using WSO2 API manager and WSO2 ESB.

wss

The message from the client would be encrypted using the public key of the ESB. The encrypted message would be sent along with the acquired OAuth token to the API Manager. The API Manager would validate the OAuth token and enforce throttling on the message. The API Manager would send the encrypted message to the ESB. The ESB would decrypt the content of the message using its own private key and send the request to the backend service.

Once the response is received from the backend service, the ESB would encrypt the message using client’s public key and send it to the API Manager. The API Manager would pass-through the message back to the client. The client would decrypt the message using its own private key.

This type of a scenario is useful in a case where

1.WS-Security needs to be enforced but cannot be enforced directly at the backend service (hence needs be enforced in an intermediary stage in the message flow).

  1. Client should be provided with a portal to explore and subscribe to API’s.
  2. API Publisher wants to manage life-cycle and manage API versioning of the exposed API’s.
  3. Throttling and other security mechanisms has to be enforced on-top of WS-Security.
  4. Statistics on API invocations needs to be gathered.