Showing posts with label WSO2-Identity Server. Show all posts
Showing posts with label WSO2-Identity Server. Show all posts

Sunday, December 18, 2011

"Entitlement Service" - XACML PDP as a web service

Being part of WSO2 middleware platform, XACML PDP (Policy Decision Point) functionality in Identity Server is exposed as a web service called 'Entitlement Service' whose implementation can be found here.

Describing XACML reference architecture and XACML policy language is out of the scope of this post and you can refer to my previous post to get an overall idea about an example solution based on XACML.

A PEP (Policy Enforcement Point) can consume the EntitlementService through a SOAP based client and invoke its "getDecision" method to obtain the authorization decision for a given XACML authorization request. Such a PEP exists in WSO2 ESB as a mediator called EntitlementMediator.

In this post, I will take you through a simple java client which acts as a PEP.

1) First of all, lets look at the communication flow between a PEP and PDP of IS with SOAP based implementation:

In the above diagram, in addition to the Entitlement Service, there is also AuthenticationAdmin service comes into play in between client and the EntitlementService.

What does it do?
It authenticates the clients against the user store before the client is capable of invoking an AdminService. Any request coming to the back end server is hit by the Authentication Handler (which is an axis2 handler) and if that request is for an AdminService, handler checks whether the request is authenticated.

Now comes the question, what is an AdminService?
Well.. In WSO2 Carbon, we have a concept called AdminService whose charaterisitcs are as follows:
  • Can only be invoked by an authenticated user in the system.
  • Exposed over secure transport.
Entitlement Service is exposed as an AdminService since it exposes the functionality of obtaining authorization decision and since it communicates security sensitive information.

You can read more about carbon authentication framework from here.

2) Before looking at the PEP client code, lets setup the PDP of IS with a sample XACML policy.

Start the identity server->login to management console->access Entitlement -> Administration -> Add New Entitlement Policy

WSO2 Identity Server has a rich XACML UI editor through which you can configure XACML policies easily.

Our XACML policy will enforce following rule: Read access to the resource called 'ABCResource' is only allowed to users belonged to admin role and all the other request to this rersource will be denied.

Please follow the following screen shots to compose the policy through UI editor (If the images are not clear, please click on them to view the enlarged version).

i). Here we define policy name, rule combining algorithm and the policy target.

ii). Next we define the two rules with 'Permit' effect for admin users and 'Deny' effect for all other requests.



iii) We can evaluate the XACML policy by sending a mock XACML request from the 'TryIt' tool provided by the Identity Server as shown below.


In the above request, a user in role 'eng' is trying to read the resource 'ABCResource' which should result in deny effect when evalated against the defined XACML policy.

iv). You can also obtain the exact XACML request created by the above 'TryIt' tool by selecting "Create Request" which you can observe as below.


3) Java client as PEP
You can download the source code of the SOAP based client which can act as a PEP and consume Entitlement Service - PDP of IS, to obtain the authorization decisions.
(Here I have only illustrated how to consume PDP, you can continue implementing a complete PEP who tracks access requests from users, composes XACML requests for those resource access requests, gets them authorized by PDP and responds to users accordingly.)

Lets go through the important code segments of the client code.
(Please note that I have trimmed off some of the code segments for the sake of brevity. Please use full source code in the above link.)
public class EntitlementClient {

    private static String serverUrl = "https://localhost:9443/services/";
    //some code goes here

    //sample XACML request captured from TryIt tool of IdentityServer. 
    private static String sampleRequest = "
                                            //actual request is removed for brevity
                                          ";

    public static void main(String[] args) {

        try {

            //set trust store properties required in SSL communication.
            System.setProperty("javax.net.ssl.trustStore",
                               "/home/hasini/WSO2/wso2is-3.2.0/repository/resources/security/wso2carbon.jks");
            System.setProperty("javax.net.ssl.trustStorePassword", "wso2carbon");
            
            //initialize authentication admin stub
            EntitlementClient remoteEntitlementClient = new EntitlementClient();

            //login using authentication admin stub providing valid credentials
            remoteEntitlementClient.login("admin", "admin");

            //initialize entitlement service stub with obtained auth cookie
            remoteEntitlementClient.initEntitlementClient();

            //invoke EntitlementService by passing the XACML request and obtain the authorization decision
            String decision = entitlementServiceClient.getDecision(sampleRequest);
            //print the authorization decision
            System.out.println(decision);

line07: hard coded XACML request which will be given as input when invoking Entitlement Service. This can be obtained from TryIt tool as described in section 2.iv

line16,18: Being AdminServices, AuthenticationAdmin and Entitlement Service are exposed over HTTPS. So here we need to set SSL system properties. Please change them to suit your environment.

line21-30: You can understand by relating the comments in the code with the communication flow illustrated in secion 1.

Setting up and running the client:
In order to run the client, please make sure you have included the two paths: "[IS_home]/lib/api" and "[IS_home]/repository/components/plugins" into your classpath.

So what?
I hope you got an idea about how PDP in IS is exposed and how to write a custom PEP to consume it and about the communication flow between the two.
In fact this is written to build up the foundation for another post I am going to write in the near future. Stay tuned.. and Have a nice day..!!

Thursday, September 29, 2011

Integration of Oracle Directory Server as the User Store of WSO2 Identity Server

WSO2 products stack supports heterogeneous user stores ranging from JDBC based databases such as MySQL, Oracle, MS-SQL to LDAP based directory servers such as Active Directory, OpenLDAP, ApacheDS...

This post explains how to setup Oracle Directory Server (or Sun Directory Server earlier) as the user store of WSO2 Identity Server.

1. Download Oracle Directory Server Enterprise Edition that suits your Operating System from here. (I am installing on Linux.. hence selected the Zip distribution)

2. Download Identity Server from here.

3. Extract the "ofm_odsee_linux_11.1.1.5.0_64_disk1_1of1.zip" distribution and locate "/ODSEE_ZIP_Distribution/sun-dsee7.zip" inside and copy it to a separate location which would be the installation directory (say install_dir).

4. Extract "sun-dsee7.zip" there and go to "dsee7/bin"

Now we are ready to create and start a Directory Server instance. I am going to follow the installation through command line .
(You can find the official installation guide from here and there are two ways of creating an instance -through directory server controller and through command line. Directory server controller way didn't work for me since it failed at registering the DCCC agent. If anyone passed that step, please share with us.)

5. Go to [install_dir]/dsee7/bin from command line and execute:
./dsadm create -p 1389 -P 1636 ../local/dsInst
Select a password for Directory Manager which we need for future operations.
You will observer following in the command line:
Choose the Directory Manager password:secret12
Confirm the Directory Manager password:secret12
Use 'dsadm start '../local/dsInst'' to start the instance

6. Start the instance:
./dsadm start /local/dsInst
Console output: Directory Server instance '/home/hasini/install_dir/dsee7/local/dsInst' started: pid=6806

7. Now we have a directory server instance running in port 1389. We need to create a root context and populate it with some sub contexts and entries for our use.
  • Let's create root as "dc=wso2,dc=org"..
    ./dsconf create-suffix -p 1389 -e dc=wso2,dc=org
 It will prompt for directory manager password which you gave at the beginning.
  • We can populate sub contexts and entries under this root, by importing a ldif file. I have created a WSO2.ldif which defines a user base, group base, admin user and admin group under the root "dc=wso2,dc=org". Download and place the file in "/dsee7/resources/ldif" directory.
  • Import the ldif file:
       ./dsconf import -p 1389 /home/hasini/install_dir/dsee7/resources/ldif/WSO2.ldif dc=wso2,dc=org
        You will be prompted to accept server certificate and for directory manager password.
        End of console output upon successful import:
        ## Import complete.  Processed 5 entries in 4 seconds. (1.25 entries/sec)
Task completed (slapd exit code: 0).

Now the directory server instance is ready for our usage and you can browse the directory tree by connecting to it through a LDAP browser such as Apache Directory Studio.

8. Provide host (localhost), port (1389) and bind DN (cn=Directory Manager), bind password (secret12) and connect Apache Directory Studio to the Oracle Directory Server instance.

9. Connecting Identity Server with Oracle Directory Server.
  • Extract the downloaded Identity Server distribution and locate the user-mgt.xml inside [IS_home]/respository/conf/user-mgt.xml
  • Comment out the existing UserStoreManager entry.
  • Uncomment the following UserStoremanager entry and edit the parameters as below:

    
            false
            ldap://localhost:1389
            cn=Directory Manager
            secret12
            SHA
            (objectClass=person)
        inetOrgPerson
            ou=Users,dc=wso2,dc=org
            (&(objectClass=person)(uid=?))
            uid
            [\\S]{5,30}
        true
        true
        true
            ou=Groups,dc=wso2,dc=org
            (objectClass=groupOfNames)
            groupOfNames
            (&(objectClass=groupOfNames)(cn=?))
            cn
            member
        
Please note edited lines: 04, 05, 06,10, 16, 17 above to integrate IS with Oracle Directory Server.
This directory server allows to create groups without an existing user. Hence line 16 parameter was set to "true".

Please note that I have connected to the directory server from IS, in read/write mode, if you want to connect in read-only mode, uncomment and change the read only LDAPUserStoreManager configuration element found in the user-mgt.xml of Identity Server.

10. Create some user entries and roles through Identity Server management console and you can browse the directory server through Apache Directory Studio and observe that they are created in directory server as below:

Thanks Prabath aiya for the request to integrating this and writing a post on it...

Wednesday, December 15, 2010

Installing multi-tenancy support for WSO2 Identity Server

Multi-tenancy is a characteristic of a cloud native platform. WSO2 stratos provides multi-tenancy. In brief, multi-tenancy is to have one instance but customizable service for each tenant isolated from one another. If you want to know more about multi-tenancy, visit wso2.org which has many resources for learning.

Thanks to the modularity of OSGI; tenant management specific components in WSO2-stratos could be installed in WSO2-carbon based products-Identity Server in this case, and provide it with the multi-tenancy support.

In this blog post, I will explain how I could install multi-tenancy support in WSO2 Identity Server.
  1. Get the Identity Server (IS) binary distribution. Either building from source or downloading binaries from here.
  2. Get the stratos-tenant management specific bundles. We can either build from the source or extract them from the binary packages. Lets go for the latter option here for the convinience. Get the Stratos released packages of from here. Download wso2stratos-manager and wso2stratos-is.
  3. Place following components from the above two packages, into Identity Server-home/repository/ components/dropins:
    • org.wso2.stratos.tenant.mgt-1.0.0.jar
    • org.wso2.stratos.tenant.mgt.ui-1.0.0.jar
    • kaptcha-2.3.0.wso2v1.jar ---these three components will install tenant management feature. But we need other components as well, in getting it fully functioning.
    • org.wso2.stratos.account.mgt.ui-1.0.0.jar
    • org.wso2.stratos.account.mgt-1.0.0.jar ---these two are related to tenant's account management.
    • org.wso2.carbon.email.verification.ui-3.1.0.jar
    • org.wso2.carbon.email.verification-3.1.0.jar
    • org.wso2.stratos.email.sender-1.0.0.jar ---these three will handle notifying tenant admin and e-mail verification after a tenant is registered.
    • org.wso2.stratos.register.ui-1.0.0.jar ---is needed to show the registration complete page after e-mail verification. (Also, it is the ui component which is used in self-tenant registration.)
    • org.wso2.stratos.identity.dashboard.ui-1.0.0.jar
    • org.wso2.stratos.identity.login.ui-1.0.0.jar ---Identity Server's UI s are replaced by these.
    • org.wso2.stratos.redirector.servlet.ui-1.0.0.jar
    • org.wso2.stratos.redirector.servlet-1.0.0.jar ---each tenant will get a url with /t/domain name. In order to handle that redirection, these two are needed.
    • org.wso2.stratos.manager.services.mgt-1.0.0.jar ---services are activated for tenants from stratos-manager. IS and G-Reg services are activated by default.
    • org.wso2.stratos.common-1.0.0.jar
    • org.wso2.stratos.activation-1.0.0.jar
    • org.wso2.stratos.service.activation-1.0.0.jar
    • org.wso2.stratos.theme.mgt.ui-1.0.0.jar
    • org.wso2.stratos.theme.mgt-1.0.0.jar ---These handles tenant's theme management, you also need to copy stratos/services/manager/distribution/resources/allThemes to IS/resources.
            4.  Change the following in configuration files:
    • add following two properties to the UserStoreManager element of user-mgt.xml in IS home/repository/conf folder:
    • false
      default
      
    • Change the carbon.xml in IS home/repository/conf to contain “WSO2 Stratos Identity” as the product name. This is because, in activating default identity service, service name is given as “WSO2 Stratos Identity”, And when checking whether a service is activated for a particular tenant, the service name is read from the carbon.xml. 
    • Give smtp server information in smtp transport sender section of axis2.xml, found in IS home/repository/conf, in order to actually send e-mail notifications upon registration of tenants by the super admin.
        5.  Copy the following configuration files from stratos-manager home/repository/conf to IS-home/repository/conf:
    • cloud-services-desc.xml
    • email-registration.xml
    • email-registration-complete.xml
    • email-update.xml
That's it...now we are done. Start IS-->log in as super admin with "admin", "admin" credentials and create tenants. Tenant admins of those tenants will be able to log in to their tenants and create users and use other functionalities provided by IS independent of other tenants registered.

I will add some screenshots to illustrate the installed multi-tenancy support in IS stand alone product.
As shown circled in the left panel of following image, multi-tenancy feature is installed in IS.

Following image shows the list of sample tenants accounts that I created for testing purposes of the functionality.

Following image shows the console of IS when user 'hasini' of tenant: 'uom.org' has signed into the IS. Notice the url circled with the part '../t/uom.org..' which is specific to that particular tenant.

When multi-tenancy/tenant management feature is installed in IS, either JDBC or embedded-ldap user-store could be used. I will explain in a future post how to configure it to use tenant aware-embedded-ldap as the user store in tenant management.