Tuesday, May 12, 2009

Creating a JDBC External User Store using WSO2 User Management component


The WSO2 User Manager is a library that lets developers handle user authentication and authorization in applications. It authenticates users from different types of user stores and currently has the capability to easily plug-in to JDBC, LDAP and AD.

Given below are the steps to tryout JDBC user store. I'll be using a MySql database for this.

1. Create a MySQL database

  • In my database I have following structure;
To create this easily rather than entering MySql statements interactively we can put the SQL statements in a file and then tell mysql to run it in batch mode. Simply copy and paste the SQL statements below in a note pad and save it with .txt extension.

/*Create a new usermgmt database */
create database usermgmt;

/*Create the users table */
create table usermgmt.users (username varchar(10) primary key,password varchar(10)) engine=innodb;

/*Create the roles table */
create table usermgmt.roles (rolename varchar(10) primary key,description varchar(15)) engine=innodb;

/*Create the userroles table */
create table usermgmt.userroles (
username varchar(10),
rolename varchar(10),
constraint un foreign key (username) references usermgmt.users(username),
constraint rn foreign key (rolename) references usermgmt.roles(rolename)
) engine=innodb;

/*Create the userprofiles table */
create table usermgmt.userprofiles (
username varchar(10),
profilename varchar(10),
email varchar(25),
postalCode varchar(5),
country varchar(10),
firstname varchar(10),
lastname varchar(10),
homephone varchar(10),
constraint un1 foreign key (username) references usermgmt.users(username)
) engine=innodb;

/*Describe the tables that were created above */
describe usermgmt.users;
describe usermgmt.roles;
describe usermgmt.userroles;

/*Insert data into the users table */
insert into usermgmt.users (username, password) values ("tamara", "tamara");
insert into usermgmt.users (username, password) values ("saman", "saman");
insert into usermgmt.users (username, password) values ("yumani", "yumani");

/*Insert data into the roles table */
insert into usermgmt.roles (rolename, description) values ("admin", "Administrator");
insert into usermgmt.roles (rolename, description) values ("guest", "Guest User");
insert into usermgmt.roles (rolename, description) values ("tester", "Tester");

/* Insert data into the userroles table */
insert into usermgmt.userroles (username, rolename) values ("tamara", "admin");
insert into usermgmt.userroles (username, rolename) values ("saman", "guest");
insert into usermgmt.userroles (username, rolename) values ("yumani", "tester");

/*Insert data into the userprofile table */
insert into usermgmt.userprofiles (username, profilename, email, postalCode, country, firstname, lastname, homephone) values ("tamara", "default", "tamara@yahoo.com", "123", "Sri Lanka", "Tamara", "Cuttilan", "1111111111");
insert into usermgmt.userprofiles (username, profilename, email, postalCode, country, firstname, lastname, homephone) values ("saman", "home", "saman@yahoo.com", "234", "SriLanka", "Saman", "Peries", "2222222222");
insert into usermgmt.userprofiles (username, profilename, email, postalCode, country, firstname, lastname, homephone) values ("yumani", "default", "yumani@yahoo.com", "345", "USA", "Yumani", "Ranaweera", "3333333333");
insert into usermgmt.userprofiles (username, profilename, email, postalCode, country, firstname, lastname, homephone) values ("yumani", "home", "yumani@gmail.com", "333", "USA", "Yumani", "Ranaweera", "4444444444");
insert into usermgmt.userprofiles (username, profilename, email, postalCode, country, firstname, lastname, homephone) values ("tamara", "home", "tamara@gmail.com", "444", "Sri Lanka", "Tamara", "Cuttilan","5555555555");

/*Retrieve table data */
select * from usermgmt.users;
select * from usermgmt.roles;
select * from usermgmt.userroles;
select * from usermgmt.userprofiles;

  • Next, open a command prompt, navigate to the location where you saved the above file.
  • Type at the prompt;

    mysql -h localhost -u root -p -t -vv< {filename}.txt
(e.g. mysql -h localhost -u root -p -t -vv <>
NOTE: -vv was put to echo the commands to the output. You can remove that if its not required.

2. Install WSO2 ESB\WSAS\IS which has User Manager component in them
  • Download a binary distribution and unzip it to your local file system.
  • I will demonstrate with WSO2 Identity Server (IS).
3. Copy the Connector/J JDBC Driver
  • This is to be able to connect to MySQL from our application.
  • Download the MySQL JDBC Driver
  • Copy and paste it to WSO2_IS_HOME\repository\components\extensions folder.
4. Start the server
  • Go to WSO2_IS_HOME\bin and execute wso2server.bat file.

    Now that we have the prerequisite ready, let's setup the external user store and tryit out.
5. Setup the external user store from WSO2 Identity Server
  • Once the server is started open a browser and access, https://localhost:9443/carbon/. You get WSO2 IS admin console.
  • Sign-in using the default admin username\password (admin\admin).
  • In the console click on 'User Management' menu option and in 'User Management' page click on 'Add External User Store' link.

  • In the 'Add External User Store' page, select to create a 'JDBC' type external user store.
  • Use following information for the rest of the fields.
(Note: Replace database name, user name, password with you information).


 



  • Now we are done with creating the external user store. The user store connections can be validated via 'Test connection' option in the External user store menu as shown below.
Let's tryout the User Management functionality in another blog post....!

Friday, April 24, 2009

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.

Thursday, March 12, 2009

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.

Thursday, February 26, 2009

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.

Friday, February 13, 2009

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.

Thursday, August 7, 2008

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.

Tuesday, July 22, 2008

WS-Security

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

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

Monday, July 21, 2008

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 !!!


Monday, July 14, 2008

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).

Friday, July 4, 2008

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.

Thursday, May 22, 2008

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"

Thursday, February 28, 2008

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

Featured

Selenium - Page Object Model and Action Methods

  How we change this code to PageObjectModel and action classes. 1 2 3 driver . findElement ( By . id ( "userEmail" )). sendKeys (...

Popular Posts