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.

 

 

 

Advertisements

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.

Adding WSO2 public certificate to Java Certificate Store

When using WSO2 Identity Server to provide OpenID Connect based SSO, you may encounter the following error,

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This is commonly observed when trying to generate an access token from the WSO2 Identity Server. This error occurs due to the fact that the public key of the WSO2 Identity Server doesnt exist in the Java certificate store. You can follow the steps given below to avoid this error.

1. Generate a public key from the WSO2 carbon keystore – To do this you would need to access the following folder. <IS HOME>\repository\resources\security. Once inside the folder, run the below command to export the public certificate.

keytool -export -keystore wso2carbon.jks -alias wso2carbon -file wso2PubCert.cer

you will be prompted to enter the password, the default password is ‘wso2carbon’. If this command is executed correctly you will see a newly created PubCert.cer certificate file in this folder.

2. Import the certificate to the Java certificate store -To import the certificate navigate to the following folder. <JavaHome>/jre/lib/security. Open a console from here and run the following command to get the number of certificates that are currently in the certificate store.

keytool -list -keystore cacerts

Default Password : ‘changeit’

This will list down all the certificates in the store. If you scroll up you would see the number of certificates in the store.

Lets import the WSO2 public certificate to this certificate store. You can do this by running the following command. For Windows users please make sure that your command prompt is running as administrator.

keytool -import -keystore cacerts -file <Certificate Path>\wso2PubCert.cer

Default Password : ‘changeit’

You will get the confirmation that the certificate is successfully imported, you can validate this by listing the certificates using the list certificates command given above.

You should now be able to access the OAuth 2.0 endpoint of the WSO2 Identity Server and generate an access token.