Previous
Next


Securing Client Without Changing Code  Locate

Now that the security for our Web service is configured, we can continue with the client side.

We will use the Java class from Example 2 as a Web service client.

Example 2. Simple Web Service Client Without Security

// Copyright 2002 Systinet Corp. All rights reserved.
// Use is subject to license terms.
package example.security;

import org.systinet.wasp.webservice.Registry;


public class Client1 {
    public static void main(String[] args) throws Exception {
        // lookup service
        ServiceIface service =
            (ServiceIface) Registry.lookup("http://localhost:6060/Service1",
                ServiceIface.class);
        System.out.println(service.doIt("hello"));
    }
}

Compile it using the Java compiler. (On UNIX systems, change each backslash (\) to a forward slash (/).)

javac -d. example\security\Client1.java

We can now run this client without changing its source code.

In WSO2 SOA Enablement Server, you can use security even with an application written without security in mind. You can specify the client identity name, password, and security mechanism using Java system properties.

The WSO2 SOA Enablement Server Security Framework supports the following system properties:

Consider again the code in Example 2. Having compiled it, we will run it using the following command. (UNIX users: change the config value to $WASP_HOME/conf/jaas.config.)

java -Dwasp.username=test -Dwasp.password=abcd -Dwasp.securityMechanism=HttpBasic -Djava.security.auth.login.config=%WASP_HOME%\conf\jaas.config example.security.Client1

Notice that setting system properties on the command line lets you run a Java client without security-related code against the Web service requiring authentication.

The client will throw a java.security.AccessControlException because the test identity does not have the permissions to call the doIt method on our Web service. The exception message will be:

Insufficient privileges, WSInvokePermission
service='/Service1' methods='doIt' permission is required.

A stack trace will follow.

To call the doIt method using the test identity, we must grant that identity permission to call this method. To do so:

  1. Click on the Web Services tree node in the WSO2 SOA Enablement Server Administration Console.

  2. Click on the /Service1 endpoint.

  3. Click the Set Endpoint Method ACL button. This opens the Service Endpoint Method ACL form.

  4. Click on the Set ACL link for the doIt method.

  5. Grant InvokePermission to the test identity by clicking grant as shown in Figure 10.

Figure 10. Setting Test Identity Permissions to doIt Method

Setting Test Identity Permissions to doIt Method

Now, we should be able to call the Web service using the test identity. To do this, type the following command (or its UNIX equivalent) again:

java -Dwasp.username=test -Dwasp.password=abcd -Dwasp.securityMechanism=HttpBasic -Djava.security.auth.login.config=%WASP_HOME%\conf\jaas.config example.security.Client1

You should see the Web service output. Now the test identity has sufficient permissions to call our Web service.

This concludes the first part of the Security Getting Started chapter. You have seen how to add security to Web services without using the Security API; by writing implementations as usual, everything is managed outside the code. The next section shows how to add security directly to the source code.



Previous
Next