How to authenticate to OIM API’s exposed as Web Service without users Password

Introduction

This document talks about how to achieve identity propagation for OIM API’s exposed as web service. The web service will be protected using OWSM. OAG is used to create the required identity assertion. They key here is authenticating to OIM without the users password.

Typical use case here is users might log into a portal and then click on a link which will invoke OIM API’s exposed as webservice.  Since user is already authenticated to portal. We won’t have the password of the user.

The custom OIM web service API won’t have access to user password. The goal is to get a OIM client handle for the propagated user without the need to have password of the user

Components required

This Article Assumes following has been installed & configured

• Domain in which OIM WLS server is created also has the EM (on Admin Server)
• OIM with couple of users created.
• OAG Node Manager
• OAG Gateway
• OAG Policy Studio
• OAG API Gateway Explorer (This is for testing the Web service request. If not installed you can also test the request using SOAPUI)

Source Code

The webservice jDeveloper Project is also distributed with this document.   You need to look at the TestWS.java for the source code

There are two methods

• getSelfServiceDetails – This doesn’t require credentials of the users which means that identity has been propagated to the WLS/OIM and Identity assertion has been done at the WLS layer.

• modifyUser – You need to pass the user who has the privileges to modify other users profile attributes.

Notice that in both methods, we are not passing the password of the user to get OIMClient handle.  WLS layer will assert the identity of the user who is passed in through webservice call which we will explore.

            Here is the link to source code zip file. You can open it in JDeveloper. 
            The final war is in deploy directory of folder TestWebService.

Create the required certificate for Encryption of WebService Request

Start OAG Node Manager, Gateway and Policy Studio

Login to Policy Studio

Click on Certificates -> Certificate with Keys -> Create/Import

Click on Edit button and add the certificate information. Click Ok to create the certificate request

For the Alias Name enter OWSM

Click on Sign Certificate

Click on Yes for self sign

Click on Yes for generating a Key Pair

You can see that private key has been created.

Click OK to close the window

Now we have to create a keystore so that this certificate can be exported and used for OWSM on the server side.

Click on KeyStore

Click on New KeyStore

Provide the Name as owsm.jks and click Ok

Enter a keystore password, Click Ok

Keystore should be created successfully

Let’s add our certificate. Click on Add to KeyStore

Search the certificate we created. We created with the Alias owsm.  Select the certificate and click Ok

Now it will ask for the alias to store the certificate in keystore.  Provide alias as owsm and enter the password you would like. Click Ok

Now you should see the certificate in keystore. Click Ok to close the dialog

Note: If you already have a keystore configured for OIM domain, you can export the certificate with key and import into your existing keystore

Update the WLS Domain with newly created KeyStore

Now we need to update the WLS domain for OIM to use the keystore we created. Since OWSM also is deployed in the same domain, it will use the certificate from keystore for decrypting the identity assertion on the server side

Copy the owsm.jks keystore created in previous step to DOMAIN_HOME/config/fmwconfig directory

Start the WLS Admin Server.

Login to EM

Select the domain -> security -> Security Provider Configuration

Under the KeyStore section click on Configure

Provide the keystore path as ./owsm.jks . Provide the Password of Keystore

Provide the key and crypt alias as owsm (you created this alias during keystore creation) & the password. Click Ok

Restart the WLS Admin Server.  Also Restart the OIM server if it’s running

Deploy the WebService

Make sure Admin Server is running

Make sure OIM server is running

Deploy the myWS.war to oim_server1 using WLS console

Now Login to EM and attach the id propagation OWSM policy to the webservice

Click on TestWSPort

Click on Attach/Detach

Select the identity propagation policy and attch

Policy should be now attached to this webservice. Click Ok

Click to get the WSDL.

Save the opened WSDL locally (Open the WSDL in IE, Firefox won’t save it properly).

Cross check the WSDL. You should see the certificate you have created being used for webservice.

Virtualize the WebService using OAG

Now lets virtualize our webservice and also attach the id propagation client policy. The use case here is that from Webservice client it will only send the header containing the remote user. OAG will attach the id propagation client policy and send the request to OIM which has the OWSM id propagation service policy attached.

In Policy Studio click on WebServices -> Register a Web Service

Select the WSDL file you saved in the last step and click on Next

Provide the User Name and Comments and click on Next

Select the WSDL operations and click Next

Let’s attach the client side policy. Click Next

Select the default services and click Finish

Now it will present the screen where you are configuring id propagation policy . Click on Signing key

Select the key owsm from the certificate store and click Next

Click Next again

Make sure you uncheck the Include password and click Finish

Click Ok

Your virtualized end point will be http://:8000/myWS/TestWSService  assuming you have kept the default OAG port.

Click on Deploy to deploy the new service

Updating the OAG Webservice Policy

We need to make updates to the OAG generated identity propagation policy.

Open the generated policy as shown below

Delete the current success Paths as shown

Search for a new filter with word http and select Retrieve from HTTP Header.  Drop this filter onto pane

Provider the Header Name as shown.  Select the Attribute ID as shown. Click on Finish

Note: We are extracting the header REMOTE_USER from client request. The REMOTE_USER indicates already authenticated user on the client. User might have authenticated to a Portal etc..

Select the success path and connect as shown

Right click on Retrieve from HTTP Header and Set as Start

Delete the other two disconnected filters which we don’t need.

Now Open the Request to Service : After Operation Hooks

Disconnect the current success path

Search for filter Sign and select the XML Signature generation and drop it on the panel

Provide the Name as Sign Header and Body

Click on the Signing Key and select owsm (alias) certificate from the certificate store

Click on sub Tab Key Info and select the option as shown

Now Click on What to Sign Tab

Select Body (Make sure to select the correct one)

Scroll Down and select UsernameToken

Click on Finish to create the filter

Now choose the Success Path and connect as shown

Right click on Sign Header and Body and Set as Start

You should see the following

Now double click on Encrypted Parts outbound Filter to open it

Now click on What to encrypt Tab and select Body (Make sure you select the correct element)

Scroll down and select UsernameToken as well

Now Click on the Message Attribute Sub Tab and uncheck the current selection

It should be as shown

Now click on Advanced Tab and make sure that following are selected for Encryption and Key Wrapping algoritham

Click on Finish to complete the filter update

Take the success path and connect as shown

Click on Server-> Deploy to deploy the change

Update the WebService Identity Propagation Policy to use AES128 Encryption

Not sure why the default encryption used by the policy is not working with OAG policy, need to check more on this.  But lets change the default encryption used.

Login to EM

Click on the - Domain -> webservices ->Policies

Search and select the ID Propagation Policy and click Edit

Make sure that you highlight the policy and click on Edit Pencil mark

Select Basic128 RSA and click Yes

Note: You can enable logging for the policy by enabling log policy as shown

Click on Save to save your changes

Restart Admin Server and  OIM Server

Testing the Integration

Let’s test the integration

Start the OAG Gateway Explorer (You can also use tools like SOAPUI)

Import the WSDL exposed by OAG Gateway

Make sure you click on the Design Tab

Click on File-> Import WSDL

Provide the WSDL exposed through API Gateway (Not the original WSDL from OIM)

Select Both Methods and click Finish

You should see the WSDL imported

Now let’s try making a call to OIM Webservice through OAG. Remember that we are simulating the already authenticated user. So we would have to pass this user as REMOTE_USER header

Make sure that getSelfUserDetails method is selected. Click on the Headers tab at the bottom and click Add on the Right side Pane

Specify the Header name as REMOTE_USER and specify any user in your OIM. Click Ok

Header should be added now

Submit the Request

You should see the Response from OIM for the selected user. Click on the Results Tab and click on the result that came back from execution

Now if we look back the flow. Client (Explorer) sends the request with already authenticated user in REMOTE_USER header (this could be user authenticating in a portal in real world and then calling the OIM WebService exposed through OAG).  OAG creates the necessary assertion according to attached Identity Propagation Policy,It also signs and encrypts the assertion.  OAG calls the OIM Webservice protected by OWSM with identity propagation assertion. OWSM validates the assertion, validates the user (OIM provider at the WLS layer) . At this point the WLS User has been created, hence OIM will allow you to call the API.

Let’s also try the other method exposed which is modifyUser

Since you are modifying the user, add a user who has privilege to modify under the tab Headers

Click on the Body Content tab and add the following

Arg0 – dcrane (user who you would like to modify)

Arg1 – What attribute needs to be modified.  Possible values are any one of the below

• Email
• Mobile
• Phone
• address

Arg2- The value for the modified attribute.

Submit the request

Click on the Results tab and look at the result

You can see that the user has been modified.  As with the previous operation we have not supplied the password for the admin user xelsysadm

OWSM Message Logging

Since we have enabled the message logging for the OWSM identity propagation service policy. Its possible to look at the assertion logged in the message logs.  You can take a look at the logs at

IDM_HOME/servers/oim_server1/logs/owsm/msglogging/diagnostic.log

OIMClient Jar file

For the source code provided. In order to compile you need the oimclient.jar file which will also be bundled with the final myWS.war file.  If you use the oimclient.war file from directory it has some problem when you deploy the webservice.

Use the oimclient.jar from role-sod.war file.  The role-sod.war is located at /server/apps

Extract the role-sod.war file. Navigate to APP-INF/lib directory. Oimclient.jar is included in this directory. Use this jar to compile the code and bundle it with final war as well.