Key Exchange Patterns with Web Services Security

When we have message level security with web services - how we achieve integrity and confidentiality is through keys. Keys are used to sign and encrypt messages been passed from the rqeuestor to the recipient or form the client to the service and vise versa.

During this blog post, we'll be discussing different key exchange patterns and their related use cases.

1. Direct Key Transfer

If one party has a token and key and wishes to share this with another party, the key can be directly transferred. WS-Secure Conversation is a good example for this. Under WS-Secure Conversation, when the security context token is created by one of the communicating parties and propagated with a message it occupies this pattern to do the key exchange. This is accomplished by the initiator sending an RSTR (either in the body or header) to the other party. The RSTR contains the token and a proof-of-possession token that contains the key encrypted for the recipient.

The initiator creates a security context token and sends it to the other parties on a message using the mechanisms described in WS-Trust specification. This model works when the sender is trusted to always create a new security context token. For this scenario the initiating party creates a security context token and issues a signed unsolicited <wst:RequestSecurityTokenResponse> to the other party. The message contains a <wst:RequestedSecurityToken> containing (or pointing to) the new security context token and a <wst:RequestedProofToken> pointing to the "secret" for the security context token.

2. Brokered Key Distribution

A third party MAY also act as a broker to transfer keys. For example, a requestor may obtain a token and proof-of-possession token from a third-party STS. The token contains a key encrypted for the target service (either using the service's public key or a key known to the STS and target service). The proof-of-possession token contains the same key encrypted for the requestor (similarly this can use public or symmetric keys).

WS-Secure Conversation also has an example for this pattern when the security context token is created by a security token service – The context initiator asks a security token service to create a new security context token. The newly created security context token is distributed to the parties through the mechanisms defined here and in WS-Trust. For this scenario the initiating party sends <wst:RequestSecurityToken> request to the token service and a <wst:RequestSecurityTokenResponseCollection> containing a <wst:RequestSecurityTokenResponse> is returned. The response contains a <wst:RequestedSecurityToken> containing (or pointing to) the new security context token and a <wst:RequestedProofToken> pointing to the "secret" for the returned context. The requestor then uses the security context token when securing messages to applicable services.

3. Delegated Key Transfer

Key transfer can also take the form of delegation. That is, one party transfers the right to use a key without actually transferring the key. In such cases, a delegation token, e.g. XrML, is created that identifies a set of rights and a delegation target and is secured by the delegating party. That is, one key indicates that another key can use a subset (or all) of its rights. The delegate can provide this token and prove itself (using its own key – the delegation target) to a service. The service, assuming the trust relationships have been established and that the delegator has the right to delegate, can then authorize requests sent subject to delegation rules and trust policies.

For example a custom token is issued from party A to party B. The token indicates that B (specifically B's key) has the right to submit purchase orders. The token is signed using a secret key known to the target service T and party A (the key used to ultimately authorize the requests that B makes to T), and a new session key that is encrypted for T. A proof-of-possession token is included that contains the session key encrypted for B. As a result, B is effectively using A's key, but doesn't actually know the key.

4. Authenticated Request/Reply Key Transfer

In some cases the RST/RSTR mechanism is not used to transfer keys because it is part of a simple request/reply. However, there may be a desire to ensure mutual authentication as part of the key transfer. The mechanisms of WS-Security can be used to implement this scenario.

Specifically, the sender wishes the following:
- Transfer a key to a recipient that they can use to secure a reply
- Ensure that only the recipient can see the key
- Provide proof that the sender issued the key

This scenario could be supported by encrypting and then signing. This would result in roughly the following steps:

1. Encrypt the message using a generated key
2. Encrypt the key for the recipient
3. Sign the encrypted form, any other relevant keys, and the encrypted key

However, if there is a desire to sign prior to encryption then the following general process is used:

1. Sign the appropriate message parts using a random key (or ideally a key derived from a random key)
2. Encrypt the appropriate message parts using the random key (or ideally another key derived from the random key)
3. Encrypt the random key for the recipient
4. Sign just the encrypted key

Most part of this blog post is extracted from WS-Trust 1.4 specification.

Understanding Entropy

This blog post is inspired by a question asked from one of my team mates - so.. here I am trying to explain what is entropy and it's role in web services security.

In information theory, entropy is a measure of the uncertainty associated with a random variable. In other words, entropy adds randomness to a generated key.

In WS-Trust, under Holder-of-Key scenario - the Security Token Service has to generate a key and pass that to the client - which will later be used between the client and the service to secure the communication.

Let's see how this is done.. Let's have a look at some part of the client request to the Security Token Service.

<wst:Entropy>
    <wst:BinarySecret
     Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce">nVY8/so9I3uvI3OSXDcyb+9kxWxMFNiwzT7qcsr5Hpw=
    </wst:BinarySecret>
   </wst:Entropy>
   <wst:ComputedKeyAlgorithm>http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1</wst:ComputedKeyAlgorithm>

Here you can see, the Entropy element is included in the request.

This optional element allows a requestor to specify entropy that is to be used in creating the key. The value of this element should be either a <xenc:EncryptedKey> or <wst:BinarySecret> depending on whether or not the key is encrypted. Secrets should be encrypted unless the transport/channel is already providing encryption. The BinarySecret element specifies a base64 encoded sequence of octets representing the requestor's entropy.

The keys resulting from a request are determined in one of three ways...

1. Specific
2. Partial
3. Omitted

In the case of specific keys, a <wst:RequestedProofToken> element is included in the response which indicates the specific key(s) to use unless the key was provided by the requestor(in which case there is no need to return it). This happens if the requestor does not provide entropy or issuer rejects the requestor's entropy.

In the case of partial, the <wst:Entropy> element is included in the response, which indicates partial key material from the issuer (not the full key) that is combined (by each party) with the requestor's entropy to determine the resulting key(s). In this case a <wst:ComputedKey> element is returned inside the <wst:RequestedProofToken> to indicate how the key is computed. This happens if the requestor provides entropy and the issuer honors it. Here you will see, in the response it will have an Entropy element - which includes the issuer's entropy.

<wst:RequestedProofToken>
    <wst:ComputedKey>http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
    </wst:ComputedKey>
   </wst:RequestedProofToken>
   <wst:Entropy>
    <wst:BinarySecret
     Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce">3nBXagllniQA8UEAs5uRVJFrKb9dPZITK76Xk/XCO5o=
    </wst:BinarySecret>
   </wst:Entropy>

In the case of omitted, an existing key is used or the resulting token is not directly associated with a key. This happens if the requestor provides entropy and the responder doesn't (issuer uses the requestor's key), then a proof-of-possession token need not be returned.

Following table summarizes the use of Entropy.

Requestor	Issuer	Result
Provides Entropy	Uses requestor entropy as key	No proof-of-possession token is returned
Provides Entropy	Provides entropy	No keys returned, key(s) derived using entropy from both sides according to method identified in response. Issuer's Entropy is returned to the client and the way the key was derived specified under ComputedKey element.
Provides Entropy	Issues own key (rejects requestor's entropy)	Proof-of-possession token contains issuer's key(s)
No Entropy provided	Issues own key	Proof-of-possession token contains issuer's key(s)
No Entropy provided	Does not issue key	No proof-of-possession token

Cross Domain Authentication Patterns - Kerberos with STS

Business Requirements : 1. Users from domain A - need to access a service in domain B 2. Not all the users from domain A should be able to access the service in domain B [only a given group of users] 3. Users are in a Windows domain and should be not asked again to enter any credentials to access the service in domain B What we need to achieve is.. User logs in to his Windows machine and seamlessly accesses the service in domain B - with no additional authentication steps. Pattern - as per the diagram above.. 1 & 2 : User talks to Kerberos KDC [TGS] - authenticates and gets a Kerberos TGT. This communication with KDC happens underneath when user logs in to his Windows machine. 3 & 4 : User program using the TGT, gets a Kerberos ticket to access the STS. 5 & 6 : Using the Kerberos ticket issued to the user to access the STS - user program authenticates to STS and obtains a SAML token via WS-Trust. STS also carries out an authorization check to see whether the user is eligible to access the service in domain B. 7 & 8 : User program uses the obtained SAML token to authenticate to the service in domain B. The service will validate that the token is issued from a trusted STS by verifying the signature.

ApacheCon Vancouver : Training on Web Services Security

Today is the first day at ApacheCon 2011 @ Vancouver - Canada.

My training on Web Services Security started around 2.30 in the afternoon.

First part was a presentation on different security patterns and standards - then started digging in to the Rampart code.

All the samples I used are available here. You can use a simple SVN client to get that code. It comes as Eclipse projects and when loaded in to an Eclipse workspace, just set the SAMPLES_HOME environment variable in ECLIPSE to the root of the downloaded code - it should build fine then... Following are some of the resources that you can look in to.. 1. http://RampartFAQ.com 2. Understanding WS – Security Policy Language 3. Applying policies at binding hierarchy 4. Password Callback Handlers Explained 5. SAML Bearer Confirmation Method, Sender Vouches & Holder-of-Key 6. Identity Delegation in WS Trust 1.4 7. WS Security Policy – Asymmetric Binding Explained

Cloud Security Videos

Open Source for Cyber Security

@4th Annual National Conference on Cyber Security, Colombo

Securing RESTful Services

Video recording available here...

Building an Enterprise SOA Security Gateway

I was looking for a 'formal' definition of 'SOA Security Gateway'. Failing to find such [yes, not even in Wikipedia] let's try to build one..

Message Interceptor Gateway pattern is the one that directly comes in to my mind.. We have implemented this at many customers with WSO2 product stack.. ESB, IS, GReg and WSAS/DSS.

This pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. The security tasks include creating, modifying, and administering security policies for sending and receiving SOAP messages. It helps to apply transport-level and message-level security mechanisms required for securely communicating with a Web services endpoint.

Isn't this the functionality we are looking from a Security Gateway..?

BTW, if you are building a Security Gateway, you can't ignore OWASP XML Security Gateway Evaluation Criteria project.

The OWASP XML Security Gateway Evaluation Criteria Project (XSGEC) defines an open standard for evaluating XML Security Gateways, such as those used to protect and provide security services for Web services applications.

This project categorizes the evaluation criteria in to 9 sections.

1. Authentication
2. Authorization
3. Audit Logging
4. Deployment Architecture
5. Content Validation
6. Management & Metrics
7. Transformation
8. Tools
9. Performance

The authentication section describes the support at the service level and message level for inbound and outbound communication to the Security Gateway.

In bound traffic can be protected with any of the following security techniques.

- Mutual SSL
- HTTP Basic Authentication
- HTTP Digest Authentication
- WS-Security Username Token Authentication
- WS-Security X.509 Certificate Based Authentication
- WS-Security: Kerberos Token
- SAML Authentication assertion
- Validation against Active Directory
- Dereference Active Directory Federation Service

Outbound traffic can be protected with following techniques..

- Mutual SSL
- HTTP Basic Authentication
- HTTP Digest Authentication
- WS-Security Username Token
- WS-Security X.509 Certificate
- WS-Security: Kerberos Token
- SAML Authentication assertion
- WS-Federation assertion

Looking at the Authorization section - it covers,

- XACML
- SAML
- LDAP

Being part of the WSO2 Security team for years now, it's so natural to think, how we meet these criteria with WSO2 Product Stack..?

In fact we do already... Only thing we lack is the full support for WS-Federation. Even a set of students from University of Moratuwa - currently working on adding WS-Federation support for Rampart - which is the security module of Axis2.

To be more precise - we have already done this at some of our customers.

Let me briefly share some of my experience with a customer who is highly concerned about security.

They had the backend services already implemented with WCF and protected with Integrated Windows Authentication[IWA] - hosted in IIS.

They have three types of clients who need access to the BE services.

1. Windows Client
2. C++ client running on a Linux box
3. Third party client - out side their domain

Windows client doesn't have any issues in accessing the BE services - with IWA.

C++ client had some technical challenges. It is already developed and only way it supports securing the communication channel to the BE services is through BasicAuthentication.

Third party client can be developed on any platform. The challenge is - we do not know how to authenticate users who are coming from a different domain - and they also need to integrate with internal windows authentication.

Apart from this - we also need to authorize each and every user.

Sounds interesting ? ;)

Let me summarize the requirements..

1. Windows Client -- [Authentication with Kerberos] -- [Authorization] -- > BE Services

2. C++ client -- [Authentication with BasicAuthentication] -- [Authorization] -- [Authentication with Kerberos] --> BE Services

3. Third Party client -- [Authentication?] -- [Authorization?] -- [Authentication with Kerberos] -- > BE Services

We need define a method to authenticate third party users - who we do not have access to the credential store -- that is WS-Trust

We need to do a credential conversion from BasicAuthentication to Kerberos and WS-Trust to Kerberos.

Apart from this we need to have an authorization scheme as well.

Let me explain our solution.

We decided to have WSO2 ESB - acting as a security gateway - implementing the message interceptor gateway pattern.

Also - we decided not to propagate end user credentials to the BE services. It's up to the ESB to authenticate and authorize users and occupy the trusted sub system pattern to authenticate to the BE with Kerberos.

1. Windows Client -- [Authentication with Kerberos] --> ESB -- [Authorization with XACML] -- [Authenticating with Kerberos] -- > BE Services

2. C++ client -- [Authentication with BasicAuthentication] --> ESB -- [Authorization with XACML] -- [Authentication with Kerberos] --> BE Services

3. Third Party client -- [Authentication with WS-Trust] --> ESB [Authorization with XACML] -- [Authentication with Kerberos] -- > BE Services




The above gives us a unified authentication and authorization scheme across three different clients.

It's true that with this pattern we do not pass user credentials to the BE services. But, still we need to send the user name corresponding to the request to the BE. In that case we wrote a mediator to extract the user name from the incoming request and attach it to the out going message form the ESB to the BE services.

Okay.. one last question.. It's clear that we can define an authorization scheme for internal users - based on their roles.. But.. how do we authorize third party users..?

All the requests [based on WS-trust] are signed by the corresponding STS. So - with the signature - we can identify to who a particular user belongs to. Internally we define roles for each and every partner and once via the signature we identified the partner, we can easily figure out the mapped role that particular user belongs to. The XACML policy authorizes the user against this role.

I guess that's pretty much the solution to that specific problem - although in my description I do not cover how to govern both the security policies and XACML policies - which should also be part of a Security Gateway Solution.

If you are further interested in reading about more features that you should look into, while building a Security Gateway - it's highly recommended that you go through Security Gateway Buyer's Guide.

Simulating a Smurf attack with Scapy

Wikipedia says..

The Smurf attack is a way of generating significant computer network traffic on a victim network. This is a type of denial-of-service attack that floods a target system via spoofed broadcast ping messages.

This attack relies on a perpetrator sending a large amount of ICMP echo request (ping) traffic to IP broadcast addresses, all of which have a spoofed source IP address of the intended victim.

If the routing device delivering traffic to those broadcast addresses delivers the IP broadcast to all hosts, most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply, multiplying the traffic by the number of hosts responding.

To simulate a Smurf attack we need to do the following..

1. Install Scapy

On Mac this is how you do it..

On Ubuntu : sudo apt-get install python-scapy

2. Send a large amount of ICMP request to the broadcast address of the victim network(Directed Broadcast Address).

3. Source IP of the attacker must be spoofed.

As per [2] when we send a ICMP request with a spoofed IP been set to the broadcast IP of the network, the server will broadcast the ICMP response to the entire network..

In the following example with Scapy, we are not using a broadcast IP - instead using an IP address of a different machine in the network.

Target machine IP : 192.168.2.11
Server machine IP : 192.168.2.10

From the attackers machine, I start Scapy;

$ sudo scapy

Then type the following - you can see the source IP been spoofed to the target machine IP.

>>> send(IP(src="192.168.2.11", dst="192.168.2.10")/ICMP())

That's it - since we want to confirm the response from the server, 192.168.2.10 goes to 192.168.2.11 - I am also running scapy there too..

$ sudo scapy

>>> a=sniff(filter="icmp and src 192.168.2.11")

The above will trace ICMP traffic targeting 192.168.2.11 - after sometime press Ctrl+C and type the following on the target machine..

>>> a.nsummary()
0000 Ether / IP / ICMP 192.168.2.11 > 192.168.2.10 echo-request 0

Smurf attacks can be prevented by,

1. Configuring the individual hosts and routers not to respond to ping requests.
2. Configuring routers not to forward packets directed to broadcast addresses.

Using 'Sign in with Twitter' ??? Read this then - You may be NOT safe

There are many application enabled for 'Sign in with Twiiter'.

http://www.twitpic.com/, http://micromobs.com/ are few to name.

Once you click on 'Sign in with Twiiter' - you are redirected to http://twitter.com/oauth/authorize page following the OAuth protocol, where you need to authorize access to the particular relying party application.

By this time, if you haven't logged in to Twitter directly, then you are asked to enter Twitter credentials as well.

These credentials are passed over the wire in clear text.

Following, I captured using Wireshark - there you can see the username and twitter password in clear text. [ I have replaced my original password with XXXXX]

authenticity_token=833dc4385cf064eea29a2ae9faddbc4ae3903659&oauth_token=O1K0VwKaFBJMDYA9f7qr53D6tqLNj4WBFmMmCONnmkI&session%5Busername_or_email%5D=prabath&session%5Bpassword%5D=XXXXX

But, when you directly login to Twitter through http://twitter.com/login - there it uses HTTPS - so you are safe.

So - if you are using 'Sign in with Twitter' - anywhere, I would rather recommend you login to Twitter directly via http://twitter.com/login and then click on 'Sign in with Twitter' link on the corresponding web site. Then you are not asked to authenticate again - only you need to do is Allow or Deny.

Hashing alone is NOT a life saver

Hashing is a one way - irreversible algorithm which is used to store passwords in databases.

So - nobody other than you know what your actual password is.

When you create your password - your password will go through the hashing algorithm and the hashed password will be stored in the database.

When you try to login - you enter your password in clear text - then the application will calculate the hash of the entered password and will match that with the hashed password already stored in the database. If matches, you will let in.

How does this make your password safe?

Say somebody hacked in to the database.But - still he cant see your password in clear text. So - he can't login to your account. Hacker will only get access to the hashed password - but not to the password in clear text. Keep in mind - you can't never login with the hashed password. That is bacause - what ever you enter as the password will go through a hashing algorithm and that hashed value will be matched with hashed password in the database. In case if you enter the value you found from the database - which is actually the hashed password - then that will be rehashed by tha application and try to match with the hashed password from the database - which will obviously fail.

But - is this safe enough ?

The hacker who has access to your database can still replace your hashed password with a hash he caculated with a clear text known to him. Then he can login to your account with the clear text known to him - because it will be evaluated against the hash value he replaced in the database.

That is; hashing alone is never safe.

Whenever you store anything in clear text as a hashed value - you need to store it as a salted hash.

In cryptography, a salt comprises random bits that are used as one of the inputs to a key derivation function. The other input is usually a password or passphrase in clear text. Output is the 'salt' value. Now - the application will caculate the hash value of password in clear text + the salt value and store that in the database.

Application will also store the salt value - but for best security, the salt value should be kept secret, separate from the password database.

When a user enters his password for login - the application will retreive the salt value and caculate the hash over both the salt and the entered password - and will match the result with the hash value stored in the password database.

In case a hacker having access to the database replaces the user's password with a hash value of a clear text known to him - still the password verification will fail - bacause now the hash is not just caculated with the password along - it's from both the password and the salt value. In this case if the hacker wants to access user account he should be able to gain access to the database which stores hash values as well.

So - the bottom line is - hashing along is never secure - salted hashing much secure - but all that will make it's hard to break - but never stop from breaking fully.

Although you store clear text passwords as salted hashes - it's never an alternative to not to secure access to the database.

Buliding your own CA infrastructure with Windows 2003

This post explains how you can build your own Certfication Authority[CA] with Windows 2003.

I have explained the same in my previous post - but with OpenSSL.

1. First make sure that you have installed Certificate Services.

2. Select stand-alone root CA.

3. Set private/public key pair for the CA.

4. Set certificate database settings.

5. Done. Your CA is ready to issue certificates.

Let's create private/public key pair for any server and generate a certificate signing request [CSR] for it.

[SAMPLE]\>keytool -genkey -alias wso2wsas -keyalg RSA -keystore wso2wsas.jks

[SAMPLE]\>keytool -certreq -keystore wso2wsas.jks -alias wso2wsas -file wso2wsas.cert.req

The above will generate the CSR - wso2wsas.cert.req, which we can submit to the CA which we just created, to get it signed.

1. Go to Control Panel --> Certification Authority.

2. Right click on WSO2CA --> All Tasks --> Submit New Request --> Submit the file wso2wsas.cert.req.

3. Now, you'll find the submitted request under, 'Pending Requests'.

4. Righ click on it --> All Tasks --> Issue.

You'll find the signed certificate under 'Issued Certificates'.

Web services security: Encryption with Rampart

This post discusses how to secure your web service with Rampart - through message encryption.

1. Setting up the environment

- Make sure you have installed Java and set your PATH env variable to C:\Program Files\Java\jdk1.5.0_06\bin [i.e : JAVA_HOME\bin]

- Download Axis2 1.4 - unzip and set the AXIS2_HOME env variable

- Download Rampart 1.4

- Copy [RAMPART_HOME]\lib\*.jar files to [AXIS2_HOME]\lib

- Copy [RAMPART_HOME]\modules\*.mar files to [AXIS2_HOME]\repository\modules

- Download Bouncy Castle jar and copy it to [AXIS2_HOME]\lib

- Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 from here and copy the two jar files from the extracted jce directory (local_policy.jar and US_export_policy.jar) to $JAVA_HOME/jre/lib/security.

- Add all the jars inside [AXIS2_HOME]\lib to your CLASSPATH [I have created a batch file for this - so you can skip this step if you want]

2. Create keystores for the service and the client

- Assume you have a folder c:\keystores and two subfolders c:\keystores\service and c:\keystores\client

- For the case of encrption client will use the public key of the service and the service will use the public key of the client.

- For the case of decryption client will use it's private key and the service will use it's private key.

- So we need to have two key pairs for both the service and the client.

- Lets first create a key pair for the service and store them in a keystore.

\> cd c:\keystores\service
\> keytool -genkey -alias service -keyalg RSA -keysize 1024 -keypass servicekey -keystore service.jks -storepass servicestorekey

- This will create a keystore "service.jks" inside c:\keystores\service

- Password of the service.jks is "servicestorekey" [-storepass servicestorekey]

- Password of the private key of the service is "servicekey" [-keypass servicekey]

- Now lets create a key pair for the client and store them in a different keystore.

\> cd c:\keystores\client
\> keytool -genkey -alias client -keyalg RSA -keysize 1024 -keypass clientkey -keystore client.jks -storepass clientstorekey

- This will create a keystore "client.jks" inside c:\keystores\client

- Password of the client.jks is "clientstorekey" [-storepass clientstorekey]

- Password of the private key of the client is "clientkey" [-keypass clientkey]

- Now we are done creating two keystores with public/private key pairs for our service and the client

- But.. as I mentioned earlier client needs to know the public key of the service and the service needs to know the public key of the client.

- So we need to export the public key of the service from the service.jks and import it to the client.jks

\> cd c:\keystores\service
\> keytool -alias service -export -keystore service.jks -storepass servicestorekey -file servicepublickey.cer
\> cd c:\keystores\client
\> keytool -import -alias service -file ../service/servicepublickey.cer -keystore client.jks -storepass clientstorekey

- Now we need to export the public key of the client from the client.jks and import it to the service.jks

\> cd c:\keystores\client
\> keytool -alias client -export -keystore client.jks -storepass clientstorekey -file clientpublickey.cer
\> cd c:\keystores\service
\> keytool -import -alias client -file ../client/clientpublickey.cer -keystore service.jks -storepass servicestorekey

- Now we are done and we have two keystores.

1. c:\keystores\client\client.jks
2. c:\keystores\service\service.jks

3. Write and deploy the service

- Download and extract rampart-sample.zip from here.

- Copy c:\keystores\service\service.jks and [rampart-sample]\service\service.properties to [AXIS2_HOME]

- Build the service

[rampart-sample]\> classpath.bat
[rampart-sample]\> cd service
\> javac org/apache/rampart/samples/sample05/*.java
\> jar cvf SimpleService.aar *

- Copy the [rampart-sample]\service\SimpleService.aar to [AXIS2_HOME]\repository\services

- Run Axis2 simple server [[AXIS2_HOME]\bin\axis2server.bat]

- Type http://localhost:8080/axis2/services/ in the browser - you will simple SimpleService being deployed.

Now, lets highlight some of the Rampart related stuff we used while creating the service.

Service should ideally use the public key of the Client to encrypt the messages it sends and use it's own private key to decrypt messages it recieves.

By now we know both these keys are in service.jks keystore and we have copied it to the service classpath - where the service can pick the required keys.

All the configuration properties related to the service.jks are written to the property file [AXIS2_HOME]\service.properties

If you open the file service.properties, you'll see the following two properties there.

org.apache.ws.security.crypto.merlin.keystore.password=servicestorekey
org.apache.ws.security.crypto.merlin.file=service.jks

Here we specify the name of the keystore to use and the password to access the keystore. [this is the password we gave while we were creating the keystore].

Now the question is, how does the service pick this service.properties file.

That - we mention in the services.xml file [[rampart-sample]\service\META-INF\services.xml].

<parameter name="OutflowSecurity">
   <action>
     <items>Encrypt</items>
     <encryptionuser>client</encryptionuser>
     <encryptionpropfile>service.properties</encryptionpropfile>
   </action>
</parameter>

If you can recall - we use the alias 'client' at the time we import the client public key to the service.jks. So the same name is used here for the encryptionuser.

The above discussion is related to encryption. How come Rampart knows the password of it's private key - to decrypt the receiving messages..

<parameter name="InflowSecurity">
      <action>
        <items>Encrypt</items>
        <passwordCallbackClass>org.apache.rampart.samples.sample05.PWCBHandler</passwordCallbackClass>
        <decryptionPropFile>service.properties</decryptionPropFile>
      </action>
</parameter>

Here the Rampart uses a callback mechanism to retrieve the password - where the service author needs to implement the password callback class [[[rampart-sample]\service\org\apache\rampart\samples\sample05\PWCBHandler.java].

4. Write and run the client

- Build the Client

[rampart-sample]\> classpath.bat
[rampart-sample]\> cd client
\> javac org/apache/rampart/samples/sample05/*.java
\> java org/apache/rampart/samples/sample05/Client http://localhost:8080/axis2/services/SimpleService.SimpleServiceHttpEndpoint C:\axis2-1.4\repository

- C:\axis2-1.4\repository is for [AXIS2_HOME]\repository

- If everything is fine client should run with no issues.

- Configurations related to Rampart is similar to the way it was discussed previously for the service.

- You'll find client.jks and client.properties at [rampart-sample]\client - which is in the path of execution.

- You'll also find password callback class at the client end at [rampart-sample]\client\org\apache\rampart\samples\sample05\PWCBHandler.java