How to deploy a Java Web Service on WSAS & secure it with Username Token Policy

A screencast by Charitha, on 'how to deploy a Java Web Service on WSAS and secure it with Username Token Policy' is now available on WSO2 Oxygen Tank and YouTube.



In this Charitha takes you through a complex scenario in a very simple manner describing each step in detail. Its really helpful for those looking for all simple details behind a complex scenario.

What unfolds after WSO2 Mashup server 1.5.2 release ....

The WSO2 Mashup Server had its 1.5.2 release in lat month (Feb-09). This had mostly the defect fixes and usability enhancements.

The fixes\enhancements as was stated in the release note are:
* Fix for the memory leak inherited via Axis2
* Fix on E-mail host object
* Fix on auto generated stubs of data services
* Minor usability enhancements

What's after 1.5.2 ....
After the 1.5.2 release the next move is for a Mashup Server release based on the WSO2 Carbon platform. At the moment the main components that will be carbonized are Javascript deployer and Host Objects.

In a Carbonized platform the Mashup server will inherit the features such as Admin UI, Security, User Management, Stubs, Transports etc from 'Core Carbon' framework.

Currently the dev team is working on this conversion .. let's wait and see what will be produced.

Enabling JMS transport in WSO2 Mashup Server

Here are the steps to enable JMS support in WSO2 Mashup Server.

1. Download apache-activeMQ and unzip it in to a folder of your selection.

2.Open axis2.xml in $MASHUP_HOME/conf directory and search for 'jms configurations' in it and uncomment those sections.

Transport Receiver syntax:
<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
<parameter name="myTopicConnectionFactory">
<parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>
</parameter>

<parameter name="myQueueConnectionFactory">
<parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
</parameter>

<parameter name="default">
<parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">tcp://localhost:61616<</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
</parameter>
</transportReceiver>


Transport Sender syntax:

<transportsender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>


3. Do the same to axis2-client.xml which also resides in the same location.

4. Copy over the following jars to the MASHUP_HOME\lib directory from activeMQ_HOME\lib
activeio-core-3.0.1.jar
activemq-core-4.1.2.jar
geronimo-j2ee-management_1.0_spec-1.0.jar

5. Start activeMQ first.

6. Start the Mashup Server.

The article submitted by Keith, to WSO2 Oxygen Tank explains invocation and exposing of JMS transport in Mashup Server with lots of background details.

Enabling Self Registration in WSO2 Mashup Server

The 'Sign-up' option in WSO2 Mashup Server blocks new user registration until admin user enables it. Steps to enable the new user sign-up are as below;

1. Login to the MS management console as the admin user.

2. Select 'Allow Internet Users' option.
Once this is enabled a window that contain the instructions required for the next steps appear.

3. As instructed from the UI go to /lib\tomcat\webapps\ROOT\WEB-INF and edit the web.xml as below;



4. Restart the server.

5. Now if you click 'Sign-up' it will present you with the 'Self Registration' page.

Enabling SMTP transport in WSO2 Mashup Server

Here is how you configure the SMTP transport in Mashup Server;


1. Add the configuration below to the axis2.xml which resides in MASHUP_HOME\conf directory.
You may need to replace the email address and password with valid details.

<transportReceiver name="mailto" class="org.apache.axis2.transport.mail.SimpleMailListener">
<parameter name="mail.pop3.host">smtp.gmail.com</parameter>
<parameter name="mail.pop3.user">username@gmail.com</parameter>
<parameter name="mail.pop3.socketFactory.class">javax.net.ssl.SSLSocketFactory</parameter>
<parameter name="mail.pop3.socketFactory.fallback">false</parameter>
<parameter name="mail.pop3.port">995</parameter>
<parameter name="mail.pop3.socketFactory.port">995</parameter>
<parameter name="mail.store.protocol">pop3</parameter>
<parameter name="transport.mail.pop3.password">password</parameter>
<parameter name="transport.listener.interval">3000</parameter>
<parameter name="transport.mail.replyToAddress">mashupserver@gmail.com</parameter>
</transportReceiver>

<transportSender name="mailto" class="org.apache.axis2.transport.mail.MailTransportSender">
<parameter name="mail.smtp.host">smtp.gmail.com</parameter>
<parameter name="mail.smtp.user">username@gmail.com</parameter>
<parameter name="transport.mail.smtp.password">password</parameter>
<parameter name="mail.smtp.starttls.enable">true</parameter>
<parameter name="mail.smtp.auth">true</parameter>
</transportSender>


2. Then add the same to the axis2-client.xml, which also resides in same place. In this case you may use a different email address and its password.

3. Since we are using a gmail address here you need to enable pop on it. Do this login to your gmail account, go to settings> Forwarding and POP/IMAP >POP Download and select 'Enable POP for mail that arrives from now on'. Save your settings.

4. Restart the WSO2 Mashup Server.

WS-Security

A really good presentation on WS-Security for a beginner.

http://www.cs.virginia.edu/~acw/security/doc/Tutorials/WS-Security.ppt

WSO2 Mashup Server released its newest version - v1.5 !!!

WSO2 Mashup Server version 1.5 was released yesterday 21, Jul 2008.


The new features for the release are ;

• Request object

• Ability to secure hosted mashups using a set of commonly used security scenarios.

• Ability to call secured services using the WSRequest host object

• Integrated Data Services Support (expose data locked up in Databases, Excel spreadsheets and CSV files with ease)

• OpenID login support

• Apache Shindig powered, Google compatible, per-user Dashboard and browser based editor support for developing gadgets for hosted mashups (http://wso2.org/library/3813).

Together with the features that were already there;

• Hosting of mashup services written using JavaScript with E4X XML extension.
• Simple file based deployment model.
• Java Script annotations to configure the deployed services
• Auto generation of meta data and runtime resources for the deployed mashups
• JavaScript stubs that simplify client access to the mashup service
• TryIt functionality to invoke the mashup service through a web browser
• WSDL 1.1/WSDL 2.0/XSD documents to describe the mashup service
• API documentation
• Ability to bundle a custom user interface for the mashups
• Many useful Javascript Host objects that can be used when writing mashups

1. WSRequest: invoke Web services from mashup services
2. File: File storage/manipulation functionality
3. System: Set of system specific utility functions
4. Session: Ability to share objects across different service invocations
5. Scraper: Extract data from HTML pages and present in XML format
6. APPClient: Atom Publishing Protocol client to retrieve/publish Atom
7. Feed: A generic set of host objects to transparently read and create Atom and RSS feeds.
8. Request: Ability get information regarding a request received
9. IM: Ability to send out instant messages from mashups.
10. Email:Ability to send out emails from mashups.

• Support for recurring and longer-running tasks
• Support for service life cycles.
• Ability to secure hosted mashups using a set of commonly used security scenarios.
• Management console to easily manage the mashups
• Simple sharing of deployed mashups with other WSO2 Mashup Servers
• Mashup sharing community portal (http://mooshup.com) to share and host your mashups
  

The complete release note details out more. I am sure everybody will enjoy mashing up their web based information more with this latest revision of WSO2 Mashup Server !!!

Few definitions used in Identiy Solutions

Some definitions related to Identity Solutions.
(listed according to the alphabetical order)


Active Requesters –
An active requester is an application (possibly a Web browser) that is capable of issuing Web services messages such as those described in WS-Security and WS-Trust.

Association –
Association is the process by which principals become associated or affiliated with a trust realm or federation.

Attribute Service -
An attribute service is a Web service that maintains information (attributes) about principals within a trust realm or federation. The term principal, in this context, can be applied to any system entity, not just a person.

Claim –
A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, attribute, etc).

Digest –
A digest is a cryptographic checksum of an octet stream.

Digital Identity -
A set of claims made by one party about another party.

Direct Trust –
Direct trust is when a relying party accepts as true all (or some subset of) the claims in the token sent by the requester.

Direct Brokered Trust –
Direct Brokered Trust is when one party trusts a second party who, in turn, trusts or vouches for, the claims of a third party.

Federation –
A federation is a collection of realms that have established trust. The level of trust may vary, but typically includes authentication and may include authorization.

Identity Mapping –
Identity Mapping is a method of creating relationships between identity properties. Some Identity Providers may make use of identity mapping.

Identity provider -
A network entity providing the digital identity claims used by a relying party.

Indirect Brokered Trust –
Indirect Brokered Trust is a variation on direct brokered trust where the second party can not immediately validate the claims of the third party to the first party and negotiates with the third party, or additional parties, to validate the claims and assess the trust of the third party.

Information card model -
Use of information cards containing meta data for obtaining digital identity claims from identity providers and then conveying them to relying parties under user control.

IP/STS –
The acronym IP/STS is used to indicate a service that is either an identity provider (IP) or security token service (STS).

Passive Requesters –
A passive requester is an HTTP browser capable of broadly supported HTTP (e.g. HTTP/1.1).

PPID (Private Personal Identifier) -

Proof-of-Possession –
Proof-of-possession is authentication data that is provided with a message to prove that the message was sent and or created by a claimed identity.

Proof-of-Possession Token –
A proof-of-possession token is a security token that contains data that a sending party can use to demonstrate proof-of-possession. Typically, although not exclusively, the proof-of-possession information is encrypted with a key known only to the sender and recipient.

Profile –
A profile is a document that describes how this model is applied to a specific class of requester (e.g., passive, or active).

Pseudonym Service -
A pseudonym service is a Web service that maintains alternate identity information about principals within a trust realm or federation. The term principal, in this context, can be applied to any system entity, not just a person.

Relying party -
A network entity providing the desired service and relying upon digital identity.

Realm or Domain –
A realm or domain represents a single unit of security administration or trust.

Security Token –
A security token represents a collection of claims.

Security Token Service (STS) -
A security token service is a Web service that issues security tokens (see WS-Security). That is, it makes assertions based on evidence that it trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security token or set of security tokens, and issues a security token with its own trust statement (note that for some security token formats this can just be a re-issuance or co-signature). This forms the basis of trust brokering.

Sender Authentication –
Sender authentication is corroborated authentication evidence possibly across Web service actors/roles indicating the sender of a Web service message (and its associated data). Note that it is possible that a message may have multiple senders if authenticated intermediaries exist. Also note that it is application-dependent (and out of scope) as to how it is determined who first created the messages as the message originator might be independent of, or hidden behind an authenticated sender.

Signed Security Token –
A signed security token is a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket)

Signature -
A signature is a value computed with a cryptographic algorithm and bound to data in such a way that intended recipients of the data can use the signature to verify that the data has not been altered since it was signed by the signer.

Simple Identity Provider -
Is the 'Self Issued Identity Provider'. Allows users to self-assert identity in the form of self issued tokens.

Signature validation –
Signature validation is the process of verifying that the message received is the same as the one sent.

Sign-Out –
A sign-out is the process by which a principal indicates that they will no longer be using their token and services in the realm can destroy their token caches for the principal.

Single Sign On (SSO) –
Single Sign On is an optimization of the authentication sequence to remove the burden of repeating actions placed on the requestor. To facilitate SSO, an element called an Identity Provider can act as a proxy on a requestor's behalf to provide evidence of authentication events to 3rd parties requesting information about the requestor. These Identity Providers (IP) are trusted 3rd parties and need to be trusted both by the requestor (to maintain the requestor's identity information as the loss of this information can result in the compromise of the requesters identity) and the Web services which may grant access to valuable resources and information based upon the integrity of the identity information provided by the IP.

Trust -
Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes.

Trust Domain/Realm -
A Trust Domain/Realm is an administered security space in which the source and target of a request can determine and agree whether particular sets of credentials from a source satisfy the relevant security policies of the target. The target may defer the trust decision to a third party (if this has been established as part of the agreement) thus including the trusted third party in the Trust Realm.

Validation Service -
A validation service is a Web service that uses the WS-Trust mechanisms to validate provided tokens and assess their level of trust (e.g. claims trusted).

WSO2 Mashup Server - Service Life Cycle support

The life cycle support in WSO2 Mashup Server uses the following annotations;

1. . init - To be called in deployment
2. .destroy -To be called in un-deployment
3. .undispatched -To get set by the dispatch logic when the operation to deliver the message to cannot be figured out.

The above were designed to support different implementations. Given below are the test cases I used for testing them.

Scenario 1: Checking the constructor\destructor implementation 1
Check if constructor and destructor are called at deployment/un-deployment times using the code below;














Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.


Scenario 2: Checking the constructor\destructor implementation 2
Check if constructor and destructor are called at deployment/un-deployment times when following format is used.












Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.


Scenario 3: Checking the constructor\destructor implementation 3
Check if constructor and destructor are called at deployment /un-deployment times when following format is used.












Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.


Scenario 4: Checking the 'undispatcher' implementation 1
Check if 'undispatched' operation is invoked when a non-existing operation is called when 'undispatched' is given in following manner.










Expected Result :
Access an invalid operation like, https://localhost:7443/services/admin/addNamespace/fooklklllklklklk the 'undispatched should be called.


Scenario 5: Checking the 'undispatcher' implementation 2
Check if 'undispatched' operation is invoked when a non-existing operation is called when 'undispatched' is given in following manner.









Expected Result :
Access an invalid operation like, https://localhost:7443/services/admin/addNamespace/fooklklllklklklk the 'undispatched should be called.

Performance Testing - Mashup Server

Mashup Server, being a downstream product of the WSO2 product suite needed to be performance tested after its integration with some other parent products.

Here's how the performance environment was setup:

Main requirement:
Test the performance of the server when performing a resource search while there's a large number of resources in the database.

Tools used:
Apache JMeter 2.2, Badboy 2.0, Selenium IDE.

Loading resources:
1. Loaded the server with 15 users.
The initial script for this was created using Badboy and exported to JMeter. In JMeter the script was executed with a 15 user data file attached to it.

2. Added 10 Mashups for each user.
This was a manual task where I copied the sample and system mashups that are shipped with the server installation, to each user folder.
(NOTE: when creating users Mashup Server creates a user folder for each user in the local file system. All resource related to the user are store in here)
*** Yes I need to automate this part...

3. Added tags and comments to each mashup of each user.
Used a Selenium script in doing this. This was quite straight forward because I simple added all resources under one login in a sequence. (I am yet to enhance this script by researching a bit on looping abilities of Selenium).

Now the test environment is ready. I have 8 scenarios identified around search functionality which exercise the database in various ways. These scripts were also initially created from BB and exported as jmx files.

Scripts and Readme files of above work can be found in: "https://wso2.org/repos/wso2/trunk/commons/qa/mashup/Test Framework/PerformanceTest"

To test 'sharing' in Mashup Server

Configurations

1. Copy the .cert file into \Java\jdk1.5.0_06\jre\lib\security
2. keytool -import -keystore cacerts -storepass changeit -alias myCert -file ca.cert
3. Change port in commandeListner & JMX in server.xml
4. In axis2.xml change the http & https ports:


Test Scenarios
1. Admin to share with a user in the same server.
2. A user sharing with the admin of the same server.
3. Admin sharing with the admin of another server.
4. Admin sharing with a user of another server.
5. User sharing with a user of another server.
6. User sharing with the admin of another server.
7. Admin sharing to a user1 of the same server and user sharing with a user2 of another server.
8. Admin sharing to a user1 of the same server and user1 sharing with admin of another server.
9. Admin sharing with user1 a service that was already shared.
10. User sharing with the admin a service that was already shared.
11. User1 sharing with a user2 in the same machine a service that is already shared.
12. User1 sharing with a user2 in another machine a service that is already shared.
13. Share and edit.
14. Share, tag\comment and share again
15. Share with a user of a same name in a different server

Open ID

WSO2 Identity Solution is going to do a release. I'll be helping them with QA. So these days I'm learning the technologies\concepts behind their new features.

Open ID is one that came first in the list. Here are some interesting links on OpenID. They were very helpful for me in gathering knowledge.

http://www.youtube.com/watch?v=DslTkwON1Bk&eurl=http://blog.facilelogin.com/search?updated-max=2007-12-17T14%3A04%3A00%2B05%3A30&max-results=10
http://www.identityblog.com/wp-content/images/2008/02/OpenID/Normal/OpenIDPhish.html
http://www.youtube.com/watch?v=xcmY8Pk-qEk