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

WSO2 Mashup Server 1.0 Beta Release

WSO2 Mashup Server 1.0 Beta was released on last 20th.
The project's src, bin distributions and all related information are available at; http://wso2.org/projects/mashup

Here are few simple scenarios that you can try with Mashups.

REGISTER YOURSELF:
Register as normal:
- Sign-up with your information
- Accept the Email Verification
- Sign-In

Register for Infor card :
- Register
- Sign-in
- Create Infor card (from profiles' page)

SWITCH USERS:
Change user:
- Sign in.
- Select the option to "Change User"
- Sign-in using a different user credentials

WORK WITH SERVICES:
Create a new service:
- Sign-In and Go to user profile page
- Select the option to "Create a new service"
- Go to service home page & select to edit service
- From the Mashups editor, update the service as you wish.
NOTE: There's a UI issue in the editor from IE7. Alternates - Works fine in FireFox

Edit a service from UI:
- Sign-In and go to the service's home page.
- Select to "edit the service"

Edit Mashups from file system:
- Go to the Mashups server directory from the file system
- Then move to the Scripts\User Folder
- Open the script from an editor
- Edit
- Save and Close
The hot update feature will re-deploy the updated the service without having the server restarted.
If your change is semantically incorrect, the server will not deploy it. The error can be viewed from server console.
You can find HELP in writing a service from Mashup Server documentation at (http://wso2.org/project/mashup/0.2/docs/index.html)

Sharing a service:
- Sign-In and Go to user profile page.
- Select the option to "Share a service"
- Give the URL for sharing server.

NOTE: If the server you are sharing to is not active, the sharing will fail)
You can also share services with the mashups.org site as well (https://mashups.wso2.org)

Start\Stop service:
- Services can be started\stopped from service's home page.

Tagging:
- Sign-in and go to a service home page
- Add a tag
The tag you added will appear under the 'tags' section of the service. If the tag you added is duplicating the Mashups server will quit intelligently will not add it. You can also add coma separated tags.

Commenting:
- Sign-in and go to a service home page
- Add a comment
The comment that you added will appear in the comments section with your user name.
Currently we allow sentences with 500 chars. However the UI wrapping go out of order if your try a WORD with 500 chars, which will be fixed for 1.0.

Scraping Assistance:
- Sign-In and Go to user profile page.
- Select to use the "scraping assistant"
Scraping assistance will help you to create a scraper configuration of your wish. You may then copy paste your configuration to the service source code.
Currently there's a small usability problem here. The option to edit a service appears in the service's home page and the scraping assistant appears only in the user home page. So currently there are too many clicks for the user to use both tools together. We will address this issue soon.

In addition to these you can also re-deploy, delete services, list falty services.

SAMPLES:
Mashups Server has some fabulous set of samples that are finely describing the technologies embedded within the server. Currently we have these appearing in the home page. You access WSDL, XSD, Source, API documentation, Tryit page, Custom UI of these sample services from the service home page which you get when clicked on the service.

SEARCHING:
You can search for Mashups, comments, Recent Activities and also search by saved queries.