Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure web services > Secure bus-enabled web services > Work with password-protected components


Password-protecting a web service operation

Password-protect individual operations (methods) in a Web service by creating an enterprise bean with methods matching the Web service operations, then applying WAS authentication mechanisms to the enterprise bean so that, before a web service operation is invoked, a call is made to the EJB method for authorization.

As well as password-protecting a web service operation as described in this topic, also configure the service as either an inbound or outbound service, and select the option to Enable operation-level security as described in Modify an existing inbound service configuration or Modify an existing outbound service configuration.

In order for an application deployed to the service integration bus to use operation-level security, set the application server class-loader policy to " single ", as described in Configure class loaders of a server.

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 then apply existing WAS 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 sibwsauthbean.ear file and the sibwsauthbean.ear file is modified to set the roles and assign them to methods. The modified sibwsauthbean.ear file is then deployed in WAS, and users are assigned to the previously-defined roles.

The installation version of the sibwsauthbean.ear file is in the WAS_HOME/installableApps directory, where WAS_HOME is the root directory for the installation of WAS.

The sibwsauthbean.ear file contains an EAR file for each web service that you protect. For the first web service that you protect through operation-level authorization, you copy the installation version of the sibwsauthbean.ear file and store your copy outside of the application server file system. For each subsequent web service that you protect, you further modify the same copy of the sibwsauthbean.ear file.

To password-protect web service operations, complete the following steps for each web service that to protect:


Procedure

  1. For the first web service that you protect, make your own copy of the WAS_HOME/installableApps/SIBWSauthbean.ear file in a convenient location outside of the application server file system.

  2. To create the your_webservice.ear file, complete the following steps:

    1. Open a command prompt.
    2. Go to the WAS_HOME/util directory.
    3. Enter the following command:
      sibwsAuthGen location your_webservice_name
      
      
      where

      • location is the service WSDL location. For an outbound service, you need the target WSDL file that is located at an external web address. For an inbound service, you need the template WSDL file that is located at the endpoint listener endpoint for the service.
      • your_webservice_name is the name of the service that you are securing, as defined in the location field of the WSDL file. This is case-sensitive.

      To get the location details for a given inbound service WSDL file, publish the WSDL file to a compressed file as described in Modify an existing inbound service configuration, then look up the location within the exported WSDL file. Alternatively, you can retrieve the inbound service WSDL file by using the following standard web services query:

      http://host_name:port_number/epl_context_root/soap//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  engine/bus_name/inbound_service_name/inbound_port_name?wsdl
      
      where host_name and port_number are the host name and port number for this application server, and epl_context_root is the context root of the endpoint listener application as described in Modify an existing endpoint listener configuration.

      Examples of using the sibwsAuthGen command:

      (outbound service):

      sibwsAuthGen http://www.somecompany.com/targetservice/wsdl/targetservice.wsdl targetServiceName
      
      
      (inbound service):
      sibwsAuthGen http://your.server.name:9080/wsgwsoap//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  1/soap//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  engine/yourbus/yourservice/inboundport1?wsdl yourservicename
      

    The your_webservice.ear file is created in the current directory. There is also a temporary directory current_directory/ejb that you can delete.

  3. To finish assigning roles and protecting methods, complete the steps given in the topic Use assembly tools to Password-protect a web service operation.

  4. To install the modified copy of the sibwsauthbean.ear file, complete the following steps:

    1. Check that the modified sibwsauthbean.ear file is stored in the convenient location outside of the application server file system that you chose in step 1. Keep the sibwsauthbean.ear file in this location for subsequent reuse and further modification.

    2. Start the WAS administrative console.

    3. In the navigation pane, click Applications -> New Application .

    4. Use the New Enterprise Application option to install the modified copy of the sibwsauthbean.ear file. Select the users or groups to assign to the roles when prompted.


Operation-level security: Role-based authorization


Related


Bus-enabled web services troubleshooting tips

+

Search Tips   |   Advanced Search