The Resource Web Service exposes a small set of actions for the resource model. The service allows remote clients to request that a resource be granted or revoked, and also to check on the status of resource requests. By exposing these actions, the service makes it possible for a provisioning workflow to invoke resource requests through the Integration activity.
Calls to the Resource Web Service calls require HTTP authentication. By default, access to the resource service methods is restricted to Resource Module Administrators.
You can access the Resource Web Service endpoint using a URL similar to the following:
http://server:port/warcontext/resource/service?test
For example, if your server is named “myserver”, your User Application is listening on port 8080, and your User Application war file is named “IDMPROV”, the URL would be:
http://myserver:8080/IDMPROV/resource/service?test
WARNING:The test page is disabled by default. Since some of the methods allow data to be updated, the test page presents a potential security vulnerability and should not be allowed in a production environment.
A SOAP service using WSSDK is deployed by adding the following declarations in the deployment descriptor (i.e. WEB-INF/web.xml):
<servlet> <servlet-name>Role</servlet-name> <servlet-class>com.novell.idm.nrf.soap.ws.role.impl.RoleServiceSkeletonImpl</servlet-class>
<servlet-mapping> <servlet-name>Role</servlet-name> <url-pattern>/role/service</url-pattern> </servlet-mapping> </servlet>
This follows the normal servlet declaration pattern. It indicates that the servlet com.novell.idm.nrf.soap.ws.resource.impl.ResourceServiceSkeletonImpl is deployed at /resource/service.
When a user reaches this servlet using a HTTP GET by entering http://server-name/context/resource/service (for example, http://localhost:8080/IDMProv/resource/service) in their browser, the WSSDK provides a page that exposes some information about the deployed service.
WARNING:The test page is disabled by default. Since some of the methods allow data to be updated, the test page presents a potential security vulnerability and should not be allowed in a production environment.
To enable the test page, you need to update the web.xml file. Before you make your changes, the web.xml should look like this:
<servlet>
<servlet-name>Resource</servlet-name>
<servlet-class>com.novell.idm.nrf.soap.ws.resource.impl.ResourceServiceSkeletonImpl</servlet-class>
<init-param>
<param-name>com.novell.soa.ws.test.disable</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
Change the servlet declaration, as follows:
<servlet>
<servlet-name>Resource</servlet-name>
<servlet-class>com.novell.idm.nrf.soap.ws.resource.impl.ResourceServiceSkeletonImpl</servlet-class>
<init-param>
<param-name>com.novell.soa.ws.test.disable</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
You can access the WSDL for the Resource Web Service using a URL similar to the following:
http://server:port/warcontext/resource/service?wsdl
For example, if your server is named “myserver”, your User Application is listening on port 8080, and your User Application war file is named “IDMPROV”, the URL would be:
http://myserver:8080/IDMPROV/resource/service?wsdl
The Resource Web Service supports two levels of security, one that restricts access to Resource Module Administrators, and another that restricts access to the authenticated user. The default setting restricts access to all operations to the Resource Module Administrator.
You can modify the security configuration by extracting the /RoleService-con/config.xml file from the IDMfw.jar file in the IDMProv.war file, and editing the property settings. Each property can be set to true or false. A value of true locks down the operation, whereas a value of false opens up the operation. After making your changes, you need to import the file back into the WAR file and redeploy.
You can open up the Resource Web Service to authenticated users by setting the ResourceService/Resource/soap property to false. To open up a particular operation to authenticated users, you need to set the property for that operation (ResourceService/Resource/soap/operation) to false as well. If you set all of the properties to false, you can open up all operations to authenticated users. The operation names are the same as the names of the methods supported by the service.
The following methods can be invoked by users without Resource Administrator credentials if the property ResourceService/Resource/soap property is set to false:
requestResourceGrant
requestResourceRevoke
getResourceRequestStatusByCorrelationId
getResourceRequestStatusForCurrentUser
getResourceAssignmentsForCurrentUser
If you wish to change the restriction for a particular operation, you can modify the property ResourceService/Resource/soap/operation for the method, setting its value to true to restrict access to administrators for the operation and false to remove the restriction. If the ResourceService/Resource/soap property is true, all methods are restricted to Resource Administrator credentials.
Example The following example shows a security configuration that would open up all operations within the Resource Web Service, except for the getResourceRequestStatusByIdentity operation, which would only be accessible to the Resource Administrator:
<property>
<key>ResourceService/Resource/soap</key>
<value>false</value>
</property>
<property>
<key>ResourceService/Resource/soap/requestResourceGrant</key>
<value>false</value>
</property>
<property>
<key>ResourceService/Resource/soap/requestResourceRevoke</key>
<value>false</value>
</property>
<property>
<key>ResourceService/Resource/soap/getResourceRequestStatusByCorrelationId</key>
<value>false</value>
</property>
<property>
<key>ResourceService/Resource/soap/getResourceRequestStatusForCurrentUser</key>
<value>false</value>
</property>
<property>
<key>ResourceService/Resource/soap/getResourceRequestStatusByIdentity</key>
<value>true</value>
</property>