Thursday Jul 17, 2014

Exploring the OIM API Wrapper (Part 1 of 2) - IDMWORKS

The need for custom OIM API operations within BPEL approval workflows happens more often than one might think. While there exists a capability to embed Java code within a BPEL workflow (with the Java Embedding activity), this is far from ideal, as anyone who has tried this will understand. In fact, the Java Embedding activity is designed to provide easy access to some basic utility code, not hundreds of lines worth of functionality. Therefore, we recommend that clients deploy custom Web Service wrappers for the OIM API calls.

This is part 1 of a 2 part series. In part 1, we will discuss developing these web service wrappers and handling security for both the OIM credentials and web service endpoints. In part 2, we'll demonstrate how to invoke these web services from your BPEL Approval Workflow (and even how to store your web service user credentials in the CSF).

Development

We’re not going to dig deep into the detail of developing these web services, mostly because it is outside the scope of this post, and there are several other fine resources out there that can walk you through creating JAX-WS web services. Refer to Oracle's documentation at the Oracle JDeveloper Tutorial page for more information.

At a high level, you can create a dynamic web project in Eclipse, and then create your classes and methods however you want. For every class that contains a web service, it must be annotated with @WebService, and every method you want to expose as an operation must be annotated with @WebMethod. Note there are some limitations on input and return parameters with web services created in this way, notably collections. For example, if you wish to return a HashMap<String, String> from a web service, you can’t do it. But if you wrap the HashMap in a wrapper class, it will work fine.

For example:

public class Response() {

public HashMap<String, String> items;

HashMap<String, String> getResponse() {};

public void setResponse(HashMap<String, String> items) {};

}

@WebMethod

public Response webOperation(String input) { … }

OIM Authentication

When invoking the API calls to OIM, you will need to authenticate with a user who has certain Administrative rights within OIM, such as xelsysadm. Creating a new OIMClient instance requires the username, password, and OIM t3 URL. In this case, the Credential Store Framework is perfectly suited to store these credentials. In our case, we store the OIM credentials using a Password key type in CSF, and the OIM t3 URL using a Generic key type.



Once the credentials were in place in the CSF, we simply invoked the CSF API (reference documentation) to retrieve the credentials. Note that the OOTB JPS policy should allow access to a key stored in the OIM map by default if your application is deployed on the Weblogic server and your classpath contains the jps-api.jar file located in the $MW_HOME/oracle_common/modules/oracle.jps_11.1.1/ directory. Otherwise, you will have to define an explicit policy (in Enterprise Manager, the System Policies screen).

Configure Web Service Policy In Owsm

Obviously exposing web service without any authentication that could create and modify users, provision accounts, etc. would be a huge risk from a security standpoint. Fortunately, you can use the Oracle Web Services Manager (OWSM) to require authentication when invoking the web services. If you use JDeveloper or the Oracle Enterprise Pack for Eclipse, you can define OWSM policies locally in your IDE. You can also do this via WLST. In our case, we’ll show you how to use Enterprise Manager to define these policies after you deploy your application.

To do this, login to Enterprise Manager and navigate Weblogic Domain -> Domain Name -> Server Name (for example, IDMDomain -> AdminServer). Right click on the server and click Web Services. You will see a list of Web Services deployed on your server.


Choose the Endpoint Name you wish to protect. The Web Service Endpoint screen will appear. Choose the OWSM Policies tab, and then click Attach/Detach. On the Attach/Detatch Policies screen, select the “oracle/wss_username_token_service_policy” policy. This will enforce a username and password for authentication on the web service call. You will see the policy appear in the “Attached Policies” section of the screen at the top.


Click OK. You will be returned to the Web Service Endpoint screen and the attached policy will be listed in the OWSM Policies list.

If you click Web Services Test (or use something similar such as SoapUI), you can validate that the policy has been applied. Click to expand the Security tab, then select the OWSM Security Policies radio button, and choose oracle/wss_username_token_client_policy from the list of available client policies. Provide the users for any user in the Weblogic domain security realm (such as the weblogic user), and click Test Web Service. Depending on your implementation, you may have to provide parameters in the Input Arguments tab, but in our case if we pass no input we just get back an error. This validates the security policy enforcement.


One important point here is that if you redeploy the web services application, you must re-apply the policies using the steps above.

That covers it for Part 1, and we hope you will check back next week for Part 2 in this blog series. 

About

Oracle Identity Management is a complete and integrated next-generation identity management platform that provides breakthrough scalability; enables organizations to achieve rapid compliance with regulatory mandates; secures sensitive applications and data regardless of whether they are hosted on-premise or in a cloud; and reduces operational costs. Oracle Identity Management enables secure user access to resources anytime on any device.

Search

Archives
« July 2014 »
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
16
18
19
20
21
22
23
24
25
26
27
28
29
  
       
Today