Single Sign On across Web Applications and Web Services

Here the requirement is to have a single sign on across Web application and Web Services. In more detail once the user is  authenticated to access a WepApp he should not only be able to access other WepApps but those WebApps also should be able to access a set of back-end services with the logged in user's access rights with no further authentication. Here the back-end services can also be configured to authorize the user based on different user claims (E.g. email).

In the situation we can assume:

•  trust relation between Identity Server and Resource Server (ESB Proxy),
•  trust relation between Identity Server and Resource Client (Web App)

The communications are:

1. User connect to the Web App with is the “Resource Client”
2. WebApp finds out user is not authenticated and redirects to the SAML2 IdP.
3. SAML2 Idp checks whether the user has an authenticated session - if not will prompt for credentials, once authenticated there ,user will be redirected back to WebApp (Resource Client)  with a SAML token, with the set of claims requested by the WebApp.
4. Now, the WebApp (Resource Client) needs to access a back-end web service with the logged in user's access rights. WebApp process the “SAML assertion token” and creates the STSToken from which it calls the Proxy Service (Resource server).
5. Proxy Service (Resource server) checks the “SAML assertion token” and allows access to the backend Web Service.

This is tested with;

•  WSO2 Identity Server 4.0.0
•  WSO2 Enterprise Service Bus 4.5.1
•  Apache Tomcat 7.0.25
•  Apache Subversion 1.6.12
•  Apache Maven 3.2.3
•  Java 1.6.0_26

Steps,

Step 1,

Download and deploy WSO2 IS 4.0.0 from http://wso2.org/products/identity-server/

Step 2
Download WSO2 ESB 4.5.1 from http://wso2.com/products/enterprise-service-bus/.
When deploying ESB change the port offsets by 1, by editing

<ESB_HOME>/repository/conf/carbon.xml file, and change the Offset element as follows
<Offset>1</Offset>


Step 3,

Download and deploy Apache Tomcat

Step 4,
Checkout https://svn.wso2.org/repos/wso2/people/suho/sso-webapp-ws sso-webapp-ws
This contains all the artifacts needed for this sample

Step 5,
Setup WSO2 IS for SSO for Web Apps

1. Login to IS
2. Click SAML SSO from the management console
   
3. Add SSO details
   
   For the avis.com WebApp
   Issuer: http://localhost:8081/avis.com/consumer
   Assertion Consumer URL: http://localhost:8081/avis.com/consumer
   Check “Enable Attribute Profile” and add the following claims
             http://wso2.org/claims/givenname
             http://wso2.org/claims/emailaddress
   For the travelocity.com WebApp
   Issuer: http://localhost:8081/travelocity.com/consumer
   Assertion Consumer URL: http://localhost:8081/travelocity.com/consumer
   Check “Enable Attribute Profile” and add the following claims
             http://wso2.org/claims/givenname
             http://wso2.org/claims/emailaddress
   When successfully added you will get Consumer Index for each entry
   
   Now the SSO setup in the WSO2 IS is done.

Step 6,

Configuring the WebApps

1. You can add these by editing the war file or edit in the src-dist and build that.
2. Edit the WEB-INF/web.xml of each WebApp and add the appropriate “Consumer Index” returned by the WSO2IS as the param-value for AttributeConsumingServiceIndex.
   
3. Edit the WEB-INF/classes/filepath.properties of each WebApp and add the appropriate
   properties. You can find all the necessary files in the resources directory.
   E.g.
   keystore.file=/<path>/sso-webapp-ws/resources/keystore/wso2carbon.jks
   repo.directory=/<path>/sso-webapp-ws/resources/repo
   bearerpolicy.file=/<path>/sso-webapp-ws/resources/bearer-policy.xml
   service.endpoint=http://localhost:8281/services/echoProxy

Step 7,

Add the proxy service

1. Login to ESB
2. Click on Add Proxy Service from the management console
   
3. Create a Pass Through Proxy
   
4. Add the proxy name and endpoint
   Proxy Service Name: echoProxy
   Target Endpoint: “Enter URL”
   Target URL: http://localhost:8281/services/echo
   And click “Create”
   
   Here the echo service (Endpoint service) is deployed on ESB by default

Step 8,

Add the policy to the registry to secure the Proxy Service

1. Click on Registry from the ESB management console
   
2. Navigate to /_system/config/repository and click on the repository
   
3. Under “Entries” click on the add recourses to add policy file
   
4. Now browse and add the bearer-policy.xml. This will be in the resources folder you
   checked out. Click “Add” to add the file.
   

Step 9,

Securing the proxy service

1. Click on List under services from the ESB management console, and click on “Unsecured” link next to the echoProxy service entry.
   
2. Select “yes”
   
3. From the “Policy From Registry” section, click in Configuration registry to add policy from the cofig registry.
   
4. Browse for the added “bearer-policy.xml” and click “OK”
   
5. Click “Next”, then click on the “admin” and “wso2carbon.jks” checkboxes, select the private key store as “wso2carbon.jks” and click on “Finish” to Activate Security.
   

Step 10,

Deploy the webapps in Tomcat

Step 11,

Go to http://localhost:8081/travelocity%2Ecom or http://localhost:8081/avis%2Ecom

1. Enter following in the redirected page
   User Name: admin
   Password: admin
   
   With successful login you will be redirected to the home page, where the Web App will be call the proxy using the “SAML assertion token” received at the SSO login.
2. With successful login at the Proxy Service you will get the following page
   Note: Here the Web Service Response will be as “Hi WSO2”
   
3. If the login at the Proxy Service fails you will get the following page
   Note: Here the Web Service Response will be as “’Hi WSO2’ expected but, no response from the web service”
   

I would like to thank the WSO2 forks; Suresh Attanayake, Prabath Siriwardena, & Balachandiran Ajanthan for helping me on this.

Enabling WSO2 ESB APIs to Pass-Through response Content-Types

This post explains how to configure WSO2ESB 4.5.x to Pass-Through response Content-Types.

WSO2 ESB is build to work on soap environments therefore WSO2 ESB (proxy service) always sends the response message in the same Content Type of the request, which is the expected behaviour.
This works fine for SOAP, because the incoming message to the proxy service and the outgoing  messages from the proxy service are both SOAP messages.

But this is not the case for REST calls, there can be cases where the proxy service need to mimic the actual service as it is.
E.g. Client sends the request in the Content-Type to be "application/json" and the Actual service receives the request in the same "application/json"  Content-Type and responds in the Content-Type of "text/plain" which the client can Accept.

This can be achieved using Message Relays, but in any case if you need to achieve this for your custom formatters you have to manually set these Content-Type as below.

<api name="api_content_type_passthrough" context="/esbsanitycheck">
  <resource methods="POST GET DELETE PUT">
     <inSequence>
        <send>
           <endpoint key="ep_esb_sanity_check"/>
        </send>
     </inSequence>
     <outSequence>
        <property name="messageType" expression="$trp:Content-Type" scope="axis2"/>
        <property name="ContentType" expression="$trp:Content-Type" scope="axis2"/>
        <send/>
     </outSequence>
  </resource>
</api>

Distributed Processing Sample for WSO2 CEP

Today we released WSO2 Complex Event Processor 2.0.0 Milestone 2.
This is available at  https://svn.wso2.org/repos/wso2/people/suho/packs/cep/wso2cep-2.0.0-M2.zip

One of the key feature of this CEP is its support for distributed processing via Siddhi CEP Engine. To demonstrate its capability I came up with a sample on distributed Processing. This sample uses Siddhi CEP Engine for processing and JMS ActiveMQ Broker to publish and subscribe events.

To run the Distributed Processing Sample follow the steps give below;
 
Step 01: Configure and run ActiveMQ in your local machine

Download the ActiveMQ from "http://activemq.apache.org/activemq-543-release.html".
unzip the distribution and run the ActiveMQ server using the command “./activemq console” from apache-activemq-xxx/bin (in Linux)
Note: WSO2CEP has been tested with ActiveMQ 5.4.3

For each CEP node in the cluster follow the steps from 02 to 08.

Step 02: Deploy CEP server 

Unzip the CEP server (Do not start the server).

      
Step 03: Change the CEP server Offset.

If you are running multiple servers in the same machine change the offset
from file "wso2cep-2.0.0-2/repository/conf/carbon.xml" to different numbers. 

E.g.

<offset>1</offset>

This is to overcome server port conflicts.
E.g. If three WSO2 servers are going to be deployed in the same machine, they can have offsets as 1, 2, and 3.

Step 04: Copy paste ActiveMQ jars.

Copy paste activemq-all-xxx.jar from the ActiveMQ home directory to 

wso2cep-2.0.0/samples/lib directory.

Copy paste activemq-core-xxx.jar and geronimo-j2ee-management_1.1_spec-1.0.1.jar
from apache-activemq-xxx/lib to wso2cep-2.0.0/repository/components/lib directory

 
Step 06: Deploy required broker management configuration

This allows CEP to receive and send messages via JMS Broker.

To deploy run "ant deploy-broker-manager" from wso2cep-2.0.0/samples/cep-samples directory.

Step 07: Configure input, output and queries

For this sample, the configurations of input, output and queries are at wso2cep-2.0.0-1/samples/cep-samples/conf/buckets/purchase-analyser-bucket.xml
When running multiple server nodes each server need to receive the input events through different topics. To enable this behaviour, open the above file and change the input topics to have different names. The default input topic name is “PurchaseTopic”.

E.g changing the names to “PurchaseTopic1”.

<input brokername="activemqJmsBroker" topic="PurchaseTopic1" />

Note : To enable distributed processing (already enabled for this sample) the change we have to do is to make the "siddhi.enable.distributed.processing" property to "true".

<engineproviderconfiguration engineprovider="SiddhiCEPRuntime">
     <property name="siddhi.persistence.snapshot.time.interval.minutes">0</property>
     <property name="siddhi.enable.distributed.processing">true</property>
</engineproviderconfiguration>

Step 08: Deploy bucket configuration

Deploy the bucket by adding the configuration purchase-analyser-bucket.xml to the directory wso2cep-2.0.0/repository/deployment/server/cepbuckets/

Step 09: Start all the servers

Start CEP servers by running "./wso2server.sh" from wso2cep-2.0.0/bin directory 

Step 10:Subscribing to output topic

Start the subscriber of the output topic "PurchaseResults" by running "ant purchaseResultsSubscriber" in a separate terminal,
from wso2cep-2.0.0/samples/cep-samples directory

Step 11:Publishing events

To publish events to all the servers (to their input topics as we defined in Step 07 ) run the publisher from wso2cep-2.0.0/samples/cep-samples directory
with the command  "ant purchasePublisher -Dtopics=xxx,xxx,..."
The client will publish events to all the given topics in a round robin manner.

E.g If we we have configured the buckets to receive the inputs via the input topics as PurchaseTopic1, PurchaseTopic2 and PurchaseTopic3

"ant purchasePublisher -Dtopics=PurchaseTopic1,PurchaseTopic2,PurchaseTopic3."

Step 12: Observation

You will be able to observe how the counts in the results steadily increases when messages are sent to any of the servers, and how the results remain consistent even when some servers goes down and comes back.

Setting brightness at Ubuntu startup

In Ubuthu machines such as Thinkpad T520 every-time when we restart the computer the brightness level will be at its maximum and then we need to manually set the brightness to a comfortable level.

To solve this issue here I share a small script I have written.

First install xdotool

sudo apt-get install xdotool

This will allow you to change the brightness easily from the command line with out admin privileges.


Check whether the brightness is changing with the following command

xdotool key XF86MonBrightnessDown

Now we have to find the file where the brightness value is stored, try doing

cat /sys/class/backlight/acpi_video0/brightness

If you get an integer value then your good to proceed, else you have to find the appropriate file in your system. In that case check in /sys/class/


Adjust the brightness and find your desired brightness level using the above command E.g. 9


In this example I have used 9 as my brightness level change it according to you.

 
#!/bin/bash

myBrightness=9;
currentBrightness=`cat /sys/class/backlight/acpi_video0/brightness`;
count=$(( $currentBrightness - $myBrightness )) ;
while [ $count -gt 0 ]
do
     xdotool key XF86MonBrightnessDown
     let  count=$(($count-1));
done

Save this as brightness.sh


Then make this file to be an executable, by running

chmod +x brightness.sh

Finally open the "Startup Applications" click Add and add the following

Name :<appropriate name>
Command:/<path to file from root>/brightness.sh
Comment:<appropriate comment>

How to install Java Cryptography Extension (JCE) unlimited strength jurisdiction policy files

How to over come "org.apache.xml.security.encryption.XMLEncryptionException: Illegal key size or default parameters" or "java.security.InvalidKeyException:illegal Key Size" error when invoking secured services

These "org.apache.xml.security.encryption.XMLEncryptionException: Illegal key size or default parameters" or "java.security.InvalidKeyException:illegal Key Size" error usually occurs when we try to invoke a web services in a secured manner and your JVM is not provisioned for Java unlimited security jurisdiction.


To provision for the Java unlimited security jurisdiction we have to install Java Cryptography Extension (JCE) unlimited strength jurisdiction policy files.


How to Install JCE

1. Go to the Oracle Java SE download page http://www.oracle.com/technetwork/java/javase/downloads/index.html
2. Scroll down ... Under "Additional Resources" section you will find "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File"
3. Download the version that matches your installed JVM E.g. UnlimitedJCEPolicyJDK7.zip
4. Unzip the downloaded zip 
5. Copy local_policy.jar and US_export_policy.jar to the $JAVA_HOME/jre/lib/security (Note: these jars will be already there so you have to overwrite them)
6. Then restart your application to get rid of this exception.