Use this task to apply security to individual methods in a Web service.
Before you begin
Before you begin this task you must first enable gateway-level authentication.
You can only apply operation-level authorization to a Web service that is already deployed to the gateway with the check box "Authorization Policy - Control access to this service" enabled.
Why and when to perform this task
For operation-level authorization you create an enterprise bean with methods matching the Web service operations. These EJB methods perform no operation and are just entities for applying security. You can apply existing WebSphere Application Server authentication mechanisms to the enterprise bean. Before any Web service operation is invoked, a call is made to the EJB method. If authorization is granted, the Web service is invoked.
Your target Web service is protected by wrapping it in an EAR file (your_webservice.ear), then applying role-based authorization to the EAR file. This process is explained in general terms in Operation-level security - role-based authorization. The your_webservice.ear file is then imported into the wsgwauth.ear file and the wsgwauth.ear file is modified to set the roles and assign them to methods. The modified wsgwauth.ear file is then deployed in WebSphere Application Server, and users are assigned to the previously-defined roles.
The wsgwauth.ear file contains an EAR file for each Web service that you protect. The installation version of the wsgwauth.ear file is in install_root/installableApps, where install_root is the root directory for your installation of IBM WebSphere Application Server (by default WebSphere/AppServer). For the first Web service that you protect through operation-level authorization, you copy the installation version of the wsgwauth.ear file and store your copy outside of the application server file system. For each subsequent Web services that you protect, you further modify the same copy of the wsgwauth.ear file.
To enable operation-level authorization, you use the WSGWAuthGen command, and the Assembly Toolkit. You can only use the tool on a Windows system, so you have to copy (in binary) to a Windows system all the files you need for this task, then create and modify the EAR files on the Windows system, then copy (in binary) the modified wsgwauth.ear file back to your z/OS system.
To enable Web service operation-level authorization, complete the following steps for each Web service that you want to protect:
Steps for this task
Copy the following files into your new directory (for example /your_dir):
Copy the following files into your new lib subdirectory (for example /your_dir/lib):
set WAS_HOME=path_to_new_directoryor
set WAS_HOME=.where path_to_new_directory is the full path to your new directory (for example C:\your_dir).
If you installed the Assembly Toolkit, and accepted the default path for the JVM, enter the following command:
PATH=C:\Program Files\IBM\ASTK\runtimes\base_v5\java\binIf you installed the Application Assembly Tool, and accepted the default path for the JVM, enter the following command:
PATH=C:\Programs\IBM\WebSphereClientDevelopmentKitforzOS\java\bin
set classpath=lib\commons-logging-api.jar;lib\j2ee.jar;lib\qname.jar;lib\wsdl4j.jar;lib\wsif.jar;lib\xerces.jar;
WSGWAuthGen location your_webservicewhere:
WSGWAuthGen http://host:port/wsgw AddressBookwhere host and port are the host name and port number for the application server on which the gateway is installed.
The Web service name and operation name can contain characters (such as a dash (-), period (.) and ampersand (&)) that are disallowed in an EJB class name and method name. Therefore these are translated during the generation process of the your_webservice.ear file. A message appears informing you of any name changes.