Saturday, April 19, 2014

WSO2 Carbon Permissions Tree and automating the permissions setting/deleting process

This is the way of setting permissions for a role using a “carbon admin service”. Basically, this is an http post request.

The endpoint is : https://localhost:9443/services/UserAdmin.UserAdminHttpsSoap11Endpoint

Replace localhost and port with carbon hostname and the https port(by default 9443)

Request Payload :

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://org.apache.axis2/xsd">
   <soapenv:Header/>
   <soapenv:Body>
      <xsd:setRoleUIPermission>
         <!--Optional:-->
         <xsd:roleName>cg_publisher</xsd:roleName>
         <!--Zero or more repetitions:-->
         <xsd:rawResources>/permission/admin/login</xsd:rawResources>
         <xsd:rawResources>/permission/admin/configure/datasources</xsd:rawResources>
      </xsd:setRoleUIPermission>
   </soapenv:Body>
</soapenv:Envelope>


Inside <xsd:roleName> element, the Role Name should be passed. If you are using external user_store like LDAP or Active Directory, this is probably the Group Name.
Inside < xsd:rawResources > element, the Permission Path should be passed. If you need to set many permissions for a role Then you can send many elements like this in the same request.

And set Basic Auth giving the username and the password of the admin user of the carbon server in the request. I’ll explain in the below section about this too, if you don’t know how to set basic auth in the request.

This is all about the request and that is all what you should do. But, for creating Permission Path string, you’ll need to understand the Permission Tree of the WSO2 carbon.

Permissions Tree

This is a predefined tree in wso2. If you need to see this tree, this is in the registry location,  /_system/governance/permission.
1.       Go to WSO2 management console Main -> Registry-> Browse
2.       Just paste the above “registry path”( /_system/governance/permission) on Location field in the registry.
3.       Expand the Properties section clicking on the “+” mark of the properties.(in the right most corner)
4.       You’ll see the Value “All Permissions”. That is the display name of that permission. We’ll need this display name later.
5.       In the Entries section, List of names(admin, protected) are permissions.

You can again click one of these permissions, you’ll get the child permissions list of this particular parent permission. You can go inside and inside until a leave gets found. And while, you are moving thru this, the Location path also getting changed. If you go a location like this /_system/governance/permission/admin/login ,  then, you won’t see any more permissions list inside login permission of the admin permission. Because, login permission is a leaf of this permission tree.

Permission Path

In the permission tree section, if you did that steps correctly, then, you should see the location path of the registry. If you remove the first two locations(/_system/governance) from that location path, the rest is the permission path. That is the string that you need to send in the above request.
Let’s say you are going to set the permissions for login to management console, The permission path for that permission is “/permission/admin/login”(without quotes).

You can give the permissions for the parents.

Suppose that you gave the permission to /permission/ of the permission tree, then, this role has every permission in the permission tree.
Suppose that you gave the permission to /permission/admin/ then, this user has the permissions for the full tree of admin.

Note

Once you send a request for setting a permission or set of permissions to a particular role, then, existing permissions of that particular role is not valid anymore. It set all the new permissions to that particular role sent in the new request. You have to list all the permissions if you need to update the permissions of a particular role like below.

Let’s say admin is the role name and it has following permissions

/permission/admin/configure
/permission/admin/manage/extensions

Now you’ll need to add the permission /permission/manage/manage_tiers also.

Then, your request body should be like.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://org.apache.axis2/xsd">
   <soapenv:Header/>
   <soapenv:Body>
      <xsd:setRoleUIPermission>
         <!--Optional:-->
         <xsd:roleName>admin</xsd:roleName>
         <!--Zero or more repetitions:-->
         <xsd:rawResources>/permission/admin/configure</xsd:rawResources>
         <xsd:rawResources>/permission/admin/manage/extensions</xsd:rawResources>
         <xsd:rawResources>/permission/manage/manage_tiers </xsd:rawResources>
      </xsd:setRoleUIPermission>
   </soapenv:Body>
</soapenv:Envelope>


Setting Basic Auth

For setting this, you have to set a header of your request. Header name is “Authorization”(without quotes). And the value should be Basic <space><base64 encoded administrator username:password pair separated by a semi colon>. Let’s say, your user name and the password is admin/admin. Base64encode the “admin:admin”(without quotes) string. That is YWRtaW46YWRtaW4= . Then, the value of the header for this example,
Name = Authorization
Value  = Basic YWRtaW46YWRtaW4=

Validation

For validating, if the permission is set or not.
1.       Send a request correctly.
2.       Log-in to Management Console.
3.       Go to Configure -> Users and Roles
4.       Go to roles and click on the permissions of the particular role, you set the permissions.
5.       This displays the graphical permission tree.
6.       Permissions assigned should have been clicked already.

Here in this large graphical tree, it uses “display name” I described in the 4th step of Permissions Tree section.

Hope you all enjoy!!!

Monday, March 17, 2014

Save your code from unsafe commits using WSO2 GitHub Pull Request Builder

WSO2 Github Pull Request Builder plugin, a Jenkins plugin, an extended version of the Github Pull Request Builder additionally facilitates merging pull requests automatically if the build went successfully if the user have asked the plugin to merge it while configuring the Jenkins job by giving the relevant config.

Prerequisites


Here, I describe how to install Jenkins on Apache-tomcat.

  1. Download Apache-tomcat.
  2. Download Jenkins as a war file.
  3. Extract tomcat to somewhere(suppose that us $TOMCAT_HOME dir)
  4. Copy the Jenkins.war file to $TOMCAT_HOME/webapps directory
  5. cd to $TOMCAT_HOME/bin and start tomcat by running
    sh catalina.sh start (if you're on linux)
    or
    catalina.bat start (if you're on windows)
  6. Then, browsing the url, http://hostname:8080/jenkins/ will take you to the Jenkins home. Please replace the hostname with the correct hostname or ip-address where the tomcat is running.
  7. The Jenkins home should look like,

  8. Get WSO2 GitHub Pull Request Builder and Updated Github Api Plugin(follow the "Build from the Source" section below).

Installing WSO2 Github Pull Request Builder on Jenkins

  1. Go to Jenkins Plugin Manager in Manage Jenkins->Manage Plugins
  2. Go to Available tab.


  3. Find the Github-Plugin and install it. You can filter the plugins using the Filter at the upper right corner.
    If you cannot find the plugin, please go to Advanced tab and try Check now at the bottom right corner and try again this step.
  4. Go to Advanced tab and upload WSO2 GitHub Pull Request Builder and Updated Github Api Plugin.
  5. Now let WSO2 GitHub Pull Request Builder get installed and restart Jenkins, that will cause Updated Github Api Plugin to replace the previously installed plugin.
  6. Now, the installation is fine.

Global Configuration

  1. Go to Jenkins Configuration in Manage Jenkins->Configure System
  2. Scroll down to the GitHub pull requests builder section.

  3. Click Advanced button and provide github Username and the Password.
  4. Scroll up to check the JDK and Maven sections too to know if the java and maven are configured. if not, please configure them too.

Job Level Configuration


  1. Go to the job page shown in Jenkins home that you need to configure the plugin. If you don't have created jobs, yet, create one by clicking on the "New Item" and provide a name and tick on the Build a maven2/3 project and click ok. Now the job should be appeared on the home as described above. Now go to the job page by clicking on the job name.

  2. Go to Configure page. Configuration should be as follows,

    1. Github project - The Github Project url
    2. This build is parameterized - Should be Checked, and add a string parameter giving some name(here we use sha1)

    3. Git Should be selected in the Source Code Management section.

      1. Repository URL - Provide the URL of the Github repo
      2. Credentials - Add credentials and select it.
      3. Refspec in Advanced - "+refs/pull/*:refs/remotes/origin/pr/*" (without double quotes, copy and paste the value)
      4. Branch Specifier (blank for 'any') - provide the build parameter name here wrapping with curly braces and a leading dollar sign(here it is ${sha1} since we used the name as sha1 before)

    4. Check GitHub pull requests builder in the Build Triggers section

      1. Admin list - Configure admin usernames in the test area
      2. Check Merge pull request automatically and Build every pull request automatically without asking (Dangerous!) in Advanced
      3. Crontab line in Advanced - "*/1 * * * *" (copy and paste the value without quotes, this value is to trigger the build in every minute, change the number to configure the number of minutes)

  3. Now save the config.

Now, You could easily test the plugin by sending a pull request to the github repo.

Build the plugin from the Source


Check out the source code. Build the code like a normal maven project in the following order.
  1. github-api
  2. github-api-plugin
  3. ghprb-plugin
Go to the targets of the 2nd and 3rd build and find .hpi files.


Wednesday, January 22, 2014

Application Life-Cycle Management using WSO2-APP-Factory

WSO2 AppFactory Provides ALM(Application Life-cycle Management) facility reducing the head-ache of setting-up and maintaining the systems in the different environments( Dev, QA and Prod). The following diagram shows the way the application moves thru the Application Life-Cycle.



Different Types of Users - Different Types of Roles

In this article, we are going to discuss about three different user-types even though AppFactory supports some more user-types. First, it is application owners. Application owners can create applications and they can do anything, no restrictions to their own applications. Second, it is Application developers. They have the access to the code and they can run it, test it and report bugs on AppFactory itself. On the other hand, developer have the access to the running application on the Dev(Developing) env too to test the app. The QAs have the access to the running applications in the QA env. They can test it and report bugs on AppFactory itself. Application owners are the only set of users discussed in this article who have the access to the running applications on the Prod(Production) env.

How does an application come to the life-cycle?

While application is on the implementing stage, there is only one code branch that is what we called trunk. That is where everybody put the code changes. Once, developers are done implementing, they need to cut the first branch providing a version. If this happens, now, AppFactory should have done everything for you. Yes, it is building the code and deploy it on the Dev env. If you go to, Life-cycle Tab as a developer working on this project, then, you'll see an application is up and running on the Dev env. So, now it has come to the life-cycle stage.

Application on the Life-Cycle

The following diagram shows the whole story of ALM in AppFactory.


As a simple description, the blue-boxes represent env's. The arrows represent either promote an app or demote from an env to another. While these promoting/demoting happen, mainly, visibility of the application changes among the people working on the app.

Hope you'll enjoy with WSO2-AppFactory