This demo shows the runtime usage of the SESJ Security API using server and client applications. It is based on the standard Hello World demo, specifically its runtime scenario. The demo is based on two Java source files:
src/demo/security/runtime/client/SecureHelloClient.java src/demo/security/runtime/server/SecureHelloServer.java
and two configuration files that are slightly modified. Both
conf/server/server.xml conf/client/client.xml
are derived from the clientconf.xml file that is contained in the WASP_HOME/conf directory. Changes are well documented inside configuration files. We have to use custom configuration files because some security features can be set only by configuration (protected store location, setting up authorization provider).
Server side starts http and https (with client authentication) transport and registers two services:
/demo/security/runtime/SecureHelloService (hello service)
classic hello service with one hello method
/demo/security/runtime/SecureHelloService/mgmt (mgmt service)
can change security requirements of the hello service
can associate credentials to hello service; it is necessary for Kerberos and WS-Security mutual authentication
mgmt service requires SSL client authentication
mgmt service requires SESJ authorization, authorization policy is based on file located at conf/server/wasp.policy
The client side invokes both services using different security mechanism and client credentials. It uses identities created by the 'create_identities' target of this demo (will be explained later here). The client performs the following actions:
Looks up both Hello service and Mgmt service
Sets application credentials that will be used during communication with Mgmt service
It sequentially performs similar actions for "no", HttpBasic, HttpDigest, WS-Security, SSL and Kerberos security providers:
sets up accepting security provider for hello service using the Mgmt service
sets up credentials for hello service using the mgmt service (only for auth. mechanisms that require mutual authentication - Kerberos, WS-Security)
sets initiating provider to hello service proxy
acquires client credentials for given security provider
sets up client credentials to hello service proxy
invokes hello service
In addition to the files described in Files and Directories, this demo contains:
| File or directory | Description |
|---|---|
| conf/server/server.xml | SESJ configuration |
| conf/server/wasp.policy | File used by server side security policy |
| conf/client/client.xml | Client SESJ configuration |
| src/demo/security/runtime/client/SecureHelloClient.java | Client side |
| src/demo/security/runtime/server/SecureHelloServer.java | Server side |
You must have installed SESJ security features before running this demo. The demo assumes that you have installed following components:
Security-Providers security_providers_client.jar - SESJ security providers Security-Tools security_tools.jar - Used by create_identities and clean_identities targets
You can run all demo parts using "run.sh" or "run.bat" scripts. Invoking the script without arguments prints out a help message.
You need to do this step in this demo only once. Issue the following command to generate identities for this demo:
run.bat(sh) create_identities
The following identities will be created on the server side:
sslServer - server side identity for SSL helloService - hello service identity used by SoapDSig
SESJ security providers The following identities will be created on the client side:
helloClient - client identity used by SSL, SoapDsig
SESJ security providers
helloAdministrator - client identity used by SSL SESJ security provider
Client identities will be trusted on the server side, server identities will be trusted on the client side. Finally, the helloClient user will be created on the server side, with password and certificate properties (helloClient identity certificate). Likewise the helloAdministrator, with the certificate property (helloAdministrator identity certificate). We thus provide mapping between SESJ user and identity certificate. Expected output is in "Appendix A" herein.
Run the command below from the command line. This should compile the server classes.
run.bat(sh) make_server
Run from the command line. This should start the server side of this demo in the background (another window in MS Windows). Note that it can take a while to boot https transport (See "Appendix B" for expected output)
run.bat(sh) run_server
Run the following command from the command line. This should create the client side of this demo.
run.bat(sh) make_client
Run the command from the command line. This should execute the client implementation. As a result, you should see the client repeatedly call the hello Web service using different authentication mechanisms. Expected output is in "Appendix C" herein. Note that only one client application can be running. Changes of accepting security mechanism for the hello service are driven by the client, which then assumes that the target hello service uses each mechanism.
run.bat(sh) run_client
You have to set up the Kerberos authentication mechanism on the server side. This authentication mechanism is provided with an implementation coming with JDK1.4, thus you have to use JDK1.4 on both client and server sides. After such configuration changes, you have to uncomment the Kerberos parts of the Java client source file.
The client part of this demo is much faster then the classic secure hello demo, because it performs only two lookup operations and then it reuses one service proxy to demonstrate SESJ security providers. The classic hello demo performs a lookup operation for each authentication mechanism, i.e. 5 (6 with Kerberos) lookups.
WS-Security is preconfigured to required UserName token authentication on both client and server side. For simplicity, the demo does not turn off WS-Security on output messages of the hello service, thus the UserName token is also used within the service response. The client is configured to validate service name and password during the create_identities step of this demo.
Creating sslServer identity on the server side... Done. Creating helloService identity on the server side... Done. Exporting sslServer identity certificate to file... Done. Exporting helloService identity certificate to file... Done. Creating helloAdministrator identity on the client side... Done. Creating helloClient identity on the client side... Done. Exporting helloAdministrator identity certificate to file... Done. Exporting helloClient identity certificate to file... Done. Ensuring trust of sslServer on the client side... Done. Ensuring trust of helloService on the client side... Done. Ensuring trust of helloAdministrator on the server side... Done. Ensuring trust of helloClient on the server side... Done. Assigning certificate property to helloAdministrator on the server side... Done. Assigning certificate and password properties to helloClient on the server side. .. Done. Assigning password property to helloService on the client side (intended for def ault setup of WS-Security)... Done.
Starting https transport ... Starting http transport ... HelloService is published on /demo/security/runtime/SecureHelloService MgmtHelloService is published on /demo/security/runtime/SecureHelloService/mgmt Server is running, press ENTER to stop server
Lookup http://sranka.in.idoox.com:6060/demo/security/runtime/SecureHelloService Lookup https://sranka.in.idoox.com:6443/demo/security/runtime/SecureHelloService /mgmt No authentication ... Invoked by 'null'. Hello, No authentication mechanism is used! HttpBasic authentication ... Invoked by 'WASPPrincipal helloClient'. Hello, HTTP Basic Authentication mechani sm is used! HttpDigest authentication ... Invoked by 'WASPPrincipal helloClient'. Hello, HTTP Digest Authentication mechan ism is used! WS-Security - Username Token authentication ... Invoked by 'WASPPrincipal helloClient'. Hello, WS-Security - Username Token is u sed! SSL client authentication ... Invoked by 'WASPPrincipal helloClient'. Hello, SSL with client authentication is used!