The 3rd Java Colombo Meetup

The third meetup of the Colombo Java User Group [JUG] was held on 19th July @ WSO2 #58 office...

Once again we had a good attendance. There were about more than 55 out of 100 registered.

Also by this meetup Java Colombo exceeded 300 subscribers and became the most active Meetup in Sri Lanka with the highest number of members.

Keynote was done by Hiranya on "Handling I/O in Java". It was the best keynote we had in Java meetups so far and was very well received by the audience. Take-away for me from the keynote is - "Hiranya's laws on I/O handling" :-). He came up with a nice set of best practices and things to avoid while doing I/O programming in Java. Hiranya has already blogged about this and can find his slides from here.

After the keynote we had the panel discussion on "Web Services with Java". Amila and Hiranya joined the panel and I had the privilege of moderating.

We started by talking about the building blocks of SOAP based web services, like SOAP, WSDL and UDDI. Then we talked briefly how to develop web services with Axis2 - where Amila also demonstrated by a sample. Further we discussed WS-Discovery and how it makes discovery less complex with respect to UDDI.

REST was also another focused topic during the discussion. Hiranya explained concepts associated with REST and explained how it differs from SOAP - when to use SOAP and when to use REST. Also we discussed limitations in REST and it's coupling to the underlying transport. Discussion finally ended up by talking about how to secure SOAP and RESTful services - where we talked about transport-level security and message-level security.

All-in-all it was successful a meetup and need to thank everyone who supported. Specially need to thank WSO2 for continuously sponsoring meetups.

Extending JMeter with a WS-Trust/STS sampler

JMeter does not have any inbuilt support for WS-Security or WS-Trust and that made me develop this STS Sampler for JMeter - which could make anyone's life better while load testing an STS.

First you need to have the Apache JMeter distribution. I am using v2.7.

Then you can download sts.sampler.zip from here - unzip it and copy the "repo" directory directly to  JMETER_HOME. Also copy all the jars inside lib.ext directory to JMETER_HOME/lib/ext.

That's it - now start the JMeter.

Under your thread group - right click - and add the Java Request Sampler...

Now, select org.wso2.apache.jmeter.sts.STSSampler as the classname - you will see the following then...

Let me briefly explain here - what exactly the different parameter names mean..

STS_End_Point : End point of the Security Token Service. If you are using the STS that comes with WSO2 Identity Server, then this would be https://localhost:9443/services/wso2carbon-sts

STS_Security_Policy : Location to the WS-Security Policy - that is being used to secure STS. It can be a security policy with UsernameToken and Sign & Encryption.

Applies_To : Against which service you are going to use this Token, obtained from the STS - or in other words, the scope of the token. This can be any URI known to the STS. STS may use this URI to find public key of that service and will use that to encrypt the key issued. So, whatever you put should be meaningful to your STS.

Token_Type : It can be any one of the following...

1. http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

2. http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

Key_Type : It can be any one of the following...

1. /SymmetricKey : A symmetric key token is requested (default)

2. /PublicKey : A public key token is requested

3. /Bearer : A bearer token is requested. This key type can be used by requestors to indicate that

they want a security token to be issued that does not require proof of possession.

Key_Size :  Size of the key. By default it's being set to 256. This is an integer element indicates the size of the key REQUIRED specified in number of bits.

Claim_Dialect : Claim dialect which is known the STS. This can be used to group set of claims together.

Required_Claims :  URIs known to the STS which indicate the required set of attributes. This can be a comma separated list.

System_Trust_Store : When the URL to the STS is on https - this indicates the location to the JKS file which includes the public certificate corresponding to the STS endpoint.

System_Trust_Store_Password : Password to access System_Trust_Store

Username :  This is required when the STS is secured with UsernameToken security policy. This is the corresponding user name.

Password : Password corresponding to the above Username.

Encryption_Key_Store :  This is required when the STS is secured with WS-Security Encryption. Location of the JKS where the public key of the STS endpoint being stored.

Encryption_Key_Store_Password : Password corresponding to the Encryption_Key_Store.

Encryption_Key_Alias : Alias from the Encryption_Key_Store corresponding to the STS endpoint. This helps to load the public key of STS.

Signature_Key_Store :  This is required when the STS is secured with WS-Security Signature. Location of the JKS where the private key of the STS client being stored.

Signature_Key_Store_Password : Password corresponding to the Signature_Key_Store.

Signature_Key_Alias : Alias from the Signature_Key_Store corresponding to the STS client. This helps to load the private key of STS client.

Signature_Key_Password : Password corresponding to the private key of the STS client.

Following is an example configuration that I used to load test STS which ships with WSO2 Identity Server.

Extending JMeter with a password digest generator

Recently I had to work on loading an OpenLDAP instance with 50,000 user records and carry on some stress testing.

JMeter was the best choice to populate the LDAP.

But.. in my case, OpenLDAP was configured not to accept any clear text passwords.

So, I could not login in with any of the random generated passwords I added via JMeter LDAP Request sampler.

This made me to write this extension to JMeter, which can be used in a generic way to generate message digest of a given text.

You can download the JAR file from here.

Then, you need to copy this to JMETER_HOME\lib\ext.

In your test plan, add a Java Request sampler to the thread group, just before where the digested text is needed. Now, select, org.wso2.apache.jmeter.message.digest.DigestGenerator.

Then you can set a hashing algorithm and which text to be digested. In that case, you can set a variable or text as it is. That's it -  once done, you can access the digest value via ${password}.