I moved my blog “Nandana Mihindukulasooriya’s Blog” to blogger sometime back but forgot to leave a note here.  So my new posts will be on “Nandana Mihindukulasooriya’s Blog” in blogger.

If you are java web service developer, you know how useful remote debugging is. So I was wondering how to enable remote debugging is Apache tomcat. It is very easy indeed. You have to just set only a single environment variable and that’s it.

In Linux,

export CATALINA_OPTS=”-Xdebug -Xnoagent /

-Djava.compiler=NONE /
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=<port>”

If you want to read more on this, please read this tutorial.

you can register for the training here.

Course Summary:

Apache Rampart is an Axis2 module that supports various service security standards. This 3-hour course is designed to give an overview on Web services security for an audience who is new to this area.

Course Objectives:

• Understand WS-Security concepts
• Learn how to use Apache Rampart to meet different security requirements

Duration:

• 3 hours

Audience:

• Beginners with a basic knowledge of XML and SOAP.

Prerequisites:

• None.

Program:

• XML-Signature
• XML Encryption
• WS-Security
  • UsernameToken authentication
  • Encryption
  • Signature
• Secure multiple messages with WS-Secure Conversation and WS-Trust
• WS-Security Policy
• Apache Implementations – WSS4J and Rampart
  • Introduction to Apache WSS4J architecture
  • Introduction to Apache Rampart architecture
• Demonstration
  • Different configuration approaches of Apache Rampart (Here we will explore all samples of the standard Apache Rampart release)
  • Setting up clients and services with parameter based and policy based configurations.
  • Securing services and clients using both dynamic and static configuration approaches.

The WSO2 WSAS team is pleased to announce the release of the WSO2 WSAS 2.2. WSO2 WSAS is an enterprise ready Web services engine powered by Apache Axis2 release under the Apache Software License 2.0.

This release can be downloaded from http://wso2.org/projects/wsas/java

Maven2 binary distribution download
- Group Id : org.wso2.wsas
- Artifact Id : wso2wsas
- Version : 2.2
- Type : zip
- WSO2 Maven2 Repository URL : http://dist.wso2.org/maven2/

Maven2 source distribution download
- Group Id : org.wso2.wsas
- Artifact Id : wso2wsas
- Version : 2.2
- Type : zip
- Classifier : src
- WSO2 Maven2 Repository URL : http://dist.wso2.org/maven2/

From the WSO2 WSAS 2.2 – Release Note – 22nd Jan 2008
=====================================================

WSO2 WSAS is an enterprise ready Web services engine powered by Apache Axis2 and which offers a complete middleware solution. It is a lightweight, high performing platform for Service Oriented Architectures, enabling business logic and applications.
Bringing together a number of Apache Web services projects, WSO2 WSAS provides a secure, transactional and reliable runtime for deploying and managing Web services.

Key Features
————
* Data services support – Expose you enterprise data as a services in a jiffy
* WSAS IDE – Eclipse IDE integration
* Clustering support for High Availability & High Scalability
* Full support for WS-Security, WS-Trust, WS-Policy and WS-Secure Conversation and XKMS
* EJB service provider support – Expose your EJBs as services
* Axis1 backward compatibility – Deploy Axis1 services on WSAS & Engage advanced WS-* protocols in front of legacy services
* JMX & Web interface based monitoring and management
* WS-* & REST support
* GUI, command line & IDE based tools for Web service development

New Features In This Release
—————————-
* Improved Data Services support including New & improved UI, and database connection pooling
* WS-Security 1.1 support
* Improved clustering support
* Improved JSR-181 & JAXWS support
* JMX based monitoring
* Graceful shutdown & restart of the server
Serve all pending requests before shutting down or restarting the server
* Improvements to the Management Console
* Various bug fixes to Apache Axis2, Apache Rampart & WSAS

Data Services – Bringing Enterprise Data to Web
———————————————–
* Service enable data locked in relational databases, CSV & Excel files in no time
* Zero code. Simple descriptor file describes the data to service mapping
* Controlled access to your data
* Customizable XML output
* Benefit from REST & WS-* support
* Built-in Connection pooling support
* Supports exposing Stored procedures & functions
* Built-in caching
* Throttling – to ensure your database is never overloaded.
* Easy configuration via graphical console
* Test your services via Try-it tool

Training
——–

WSO2 Inc. offers a variety of professional Training Programs, including
training on general Web services as well as WSO2 WSAS, Apache Axis2, Data Services
and a number of other products.

For additional support information please refer to
http://wso2.com/training/course-catalog/

Support
——-

WSO2 Inc. offers a variety of development and production support
programs, ranging from Web-based support up through normal business
hours, to premium 24×7 phone support.

For additional support information please refer to http://wso2.com/support/

For more information on WSO2 WSAS, visit the WSO2 Oxygen Tank (http://wso2.org)

How to do various things with WSAS – WSAS HOWTO Series(http://wso2.org/library/2707)

For further information see the full release note http://wso2.org/project/wsas/java/2.2/docs/release_notes.html

Thanks for your interest in WSO2 WSAS
— WSO2 WSAS Team

Web services security policy language defines a way to express constraints and requirements of a soap message to provide security. These constraints and requirements are defined as policy assertions and these assertions define how messages are secured. These assertions can be categorized in to

• Security binding assertions
• Protection assertions
• Token assertions
• Supporting token assertions
• WSS : Soap message security assertions
• WS – Trust assertions

Security Binding Assertions

Security binding assertions defines main security mechanism used to secure the messages. This assertion defines some properties and these properties define how messages are secured. These also defines which tokens should be used to secure messages using Token assertions. There are 3 security binding assertions, Transport binding, Symmetric binding and Asymmetric binding. If transport binding is used, message protection is provided by means other than SOAP message security. For example, Transport biding can use HTTPS transport to secure the message between the client and the server. If we use Asymmetric binding assertion, we can easily make both the client and server authenticate them selves using the security tokens defined in this policy assertion. Under this assertion we can specify two requirements with initiator token assertion and recipient token assertion. These assertions defines what type of token should be used by initiator and recipient. When Symmetric binding is used , first encrypted key is derived using the recipients security token , defined in the either encryption token assertion or protection token assertion. Then this encrypted key is used to secure the message back and forth between the recipient and the initiator. This binding facilitates the need to secure the messages between anonymous clients and the server. Only the server has to posses a security token.

Security Binding Properties

Security biding assertions contain some properties which defines how messages are secured.

• Algorithm Suite – this property defines a algorithmic suite to be used with cryptographic operations. So it is very easy to define all the algorithms using one property. What are the available algorithmic suites and which algorithms are used in those suites can be found in the WS – Security Policy specification.
• Timestamp – defines whether timestamp should be included in the message
• Protection Order – when we have to do both signature and encryption, this defines whether to sign then encrypt or encrypt then sign.
• Signature Protection – defines whether signature should be encrypted. Signature confirmation elements also will be encrypted.
• Token protection – defines whether signature should cover the security token which used to generate the signature
• Entire Header and Body Signatures – defines whether signatures should cover only the entire body and entire header elements and not the descendant of elements.
• Security Header Layout – defines layout rules which applies to security header

Protection Assertions

These assertions defined what message parts are protected and how they are protected. There are mainly two types of protection token assertions. Integrity Assertions and Confidentiality Assertions. Integrity assertions define what elements of the message should be signed and confidentiality assertions defines what elements should be encrypted. Four protections assertions are

• Signed Parts Assertion – defines whether body should be signed and what soap header elements should be signed
• Signed Elements Assertion – defines arbitrary elements to be signed using XPath
• Encrypted Parts Assertion – defines whether body should be signed and what soap header elements should be encrypted
• Encrypted Elements Assertion – defines arbitrary elements to be encrypted using XPath

Token Assertions

These assertions specify the type of the tokens to be used to protect the messages. These assertions also define two important properties about the tokens used to protect the message.

• Token Inclusion – defines when to include the binary tokens in the message
• Derived Keys – defines whether derived keys should be used

some of the token types defined in the WS – Security Policy specification are,

• Username Tokens
• X509 Tokens
• Issued Tokens
• Secure Conversation Tokens
• SAML Tokens
• Https Tokens

Supporting Token Assertions

These tokens defines additional tokens to augment the claims provide by the token which is used to generate the message signature. There are four types of supporting tokens.

• Supporting Tokens – additional tokens to included in the security header
• Singed Supporting Tokens – additional tokens to be included in the security header which are also covered by the message signature
• Endorsing Supporting Tokens – These tokens sign the message signature ( entire ds:Signature element ). So we get an additional signature element which is the signature of the original message signature.
• Signed Endorsing Supporting Tokens – Here the supporting token is covered by the message signature. And the message signature again is signed using the supporting token.

WSS – SOAP Message Security Options

These options defines the requirements that the initiator and the recipient must support. There are two assertions , Wss10 assertion and Wss11 assertion which defines these requirements.

Wss10 Assertion

• Direct References – defines whether initiator and recipient must be able to process direct reference
• Key Identifier References – defines whether initiator and recipient must be able to process key identifier references
• Issuer Serial References – defines whether initiator and recipient must be able to process issuer serial references
• External URI References – defines whether initiator and recipient must be able to process external URI references
• Embedded Token References – defines whether initiator and recipient must be able to process embedded token references

Wss11 Assertion

• Thumbprint References – defines whether initiator and recipient must be able to process thumbprint references
• EncryptedKey References – defines whether initiator and recipient must be able to process encrypted key references
• Signature Confirmation – defines whether signature confirmation as defined in SOAP Message Security 1.1 specification

WS – Trust Assertions

This assertion defines the requirements for exchanges based on WS-Trust, specifically with client and server challenges and entropy behaviors.

Recently there was few mails about problems faced when using the Username token as supporting tokens along with X509 certificates. In these scenarios we use X509 Certificate to sign the message and also attach Username Token as a supporting token. So let’s see how we can configure rampart for these scenarios. I always preferred the policy based configuration so here also I will use policy based configuration as it is more flexible ( my opinion ) than the basic way of rampart configuration.

When we use both Username and X509 Certificate, there are 4 scenarios possible.

1. X509 Certificate ( which is used to sign ) alias and the username is the same. Cert password and Username Token password is the same.

2. X509 Certificate ( which is used to sign ) alias and the username is the same. Cert password is different from the password of the Username Token.

3. X509 Certificate ( which is used to sign ) alias and the username is different. Cert password and the Username Token password is the same.

4. X509 Certificate ( which is used to sign ) alias and the username is different. Cert password and the Username Token password is different.

Rampart can cater all these four situations. But before we look at how to configure rampart in each of these situations, let’s look at how rampart uses password callback in above situations. There are two situation we use the password callback. One is to extract user’s cert password when we want to get that key to sign the message. Second one is when we want to create a Username Token with the password.

Signature
Get the user – First check whether userCertAlias present
String user = rpd.getRampartConfig().getUserCertAlias();
// If userCertAlias is not present, use user property as Alias
if (user == null) {
user = rpd.getRampartConfig().getUser();
}
CallbackHandler handler = RampartUtil.getPasswordCB(rmd);
WSPasswordCallback[] cb =

{ new WSPasswordCallback(user,WSPasswordCallback.SIGNATURE) };
handler.handle(cb);
password = cb[0].getPassword();

Username Token
user = rpd.getRampartConfig().getUser();
CallbackHandler handler = RampartUtil.getPasswordCB(rmd);
WSPasswordCallback[] cb =

{ new WSPasswordCallback(user,WSPasswordCallback.USERNAME_TOKEN) };
handler.handle(cb);
password = cb[0].getPassword();

There are two important things to note. First thing is when we want to get the password of a Username Token with a given username, we set the usage of the callback to WSPasswordCallback.USERNAME_TOKEN. If what rampart want is the cert password, it sets the usage toWSPasswordCallback.SIGNATURE as you can see in the latter case. We can use this usage parameter in our callback to provide the correct password according to usage. Second thing is the before you when it is signature, we first check whether userCertAlias parameter is set and if it is set we use it as the cert alias. If it is not set Rampart will use the good old user parameter as the cert alias of the certificate used in signature.

Now lets see how can we configure Rampart in each of the above scenarios.

Scenario 1 : Say both username and cert alias is “Alice” and password is “password”.

So first we set both the username of the Username Token and the cert alias using “user” parameter in Rampart config. What are the parameters available in Rampart config can be found here.

<ramp:user>Alice</ramp:user>

and all you need is a simple callback,

public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[0];

String id = pwcb.getIdentifer();

    if(“Alice”.equals(id) ) {
pwcb.setPassword(“password”);
}

}

Scenario 2 : Say both username and cert alias is “Alice”. But the password of the Username Token id “password” and password of the cert is “password2″. Here also we only need to set the “user” parameter to “Alice” in the Rampart config. But in the password callback , we have make use of the usage property to provide the correct password.

String id = pwcb.getIdentifer();

int usage = pwcb.getUsage();

if(“Alice”.equals(id) && usage == WSPasswordCallback.USERNAME_TOKEN) {
pwcb.setPassword(“password”);
}else if (“Alice”.equals(id) && usage == WSPasswordCallback.SIGNATURE) {
pwcb.setPassword(“password2);
}

Scenario 3 : Now the username of Username Token is “Alice” and alias for the cert is “Alice2″. Password for both cases is “password”. Here we can’t just do only with “user” parameter of the Rampart config. So we use both “user” parameter and “userCertAlias” parameter.

<ramp:user>Alice</ramp:user>

<ramp:userCertAlias>Alice</ramp:userCertAlias>

callback used in the scenario 1 will work for this too.

Scenario 4: Here the username of Username Token is “Alice” and alias for the cert is “Alice2″.And the password of the Username Token id “password” and password of the cert is “password2″. In this scenario we have to use the Rampart configuration used in scenario 3 and the password callback used in scenario 2.

To learn more about how to configure Rampart , go through the samples modules which are shipped with Rampart distribution. Rampart current release can be downloaded here.

I always wanted to be a blogger since I was in uni. But it never worked out. Main reason, was the connectivity. When I was connected I didn’t have the time to blog. When I was free at home I didn’t have the connectivity. So at last I thought I would go for a offline blogging tool. So here am I with Qumana , hopefully it will work for me. 

Powered by Qumana