OAuth2 has become increasingly popular for authorizing access to web services. Invoking these services is possible by applying Oracle Web Services Manager (OWSM) policies to the component in the composite. OWSM actually acquires the OAuth Access Token and includes it in the HTTP request to the resource server for you automatically. This blog describes the steps needed to setup and utilize OAuth2 protected services from a BPEL composite.
** NOTE **: There is a known issue where tokens do not get refreshed upon expiry. This has been addressed in Bug 27362824.
The steps below are divided into two categories:
After provisioning a SOACS instance, there are a couple of steps remaining in order to utilize OWSM policies. These steps only need to be performed one time.
OWSM requires a safe place to store keys (both private and public). In our case we’re not actively using any key pairs but OWSM will throw an error if the keystore has not been created. So we need to create an empty keystore with a specific path or stripe and name to avoid that error.
To create this keystore in the proper location use the Enterprise Manage (EM) console to perform the following steps:
The OPSS Credential Store contains zero or more Credential Maps. And those Maps then contain zero or more “Keys”. A key in this context may be a username and password or it could be generic textual data. In our case we need to store an OAuth Client ID and Secret which are effectively a username and password.
As with the Keystore above, the necessary Credential Map is not created at provisioning time and so we need to manually create it ourselves.
To create the Credential Map open the EM console and perform the following steps:
The following steps have to be completed for each remote service invoked by a BPEL composite.
In order for your composite to invoke the OAuth2 protected service, the application it represents should have been registered with the provider and a client ID and secret generated. This client ID and secret are used to retrieve the access token needed to invoke the service. These credentials need to be stored in a secure location such that even if the SOA server is compromised, or an administrator was to “go rogue”, the password would still be safe. FMW provides a secure place for this called the OPSS Credential Store.
Next we need to store the actual username and password (again OAuth client ID and secret).
To do that:
Fill in the Key field with a name. We will use this name in the next step so note the value you choose.
You should end up with something like the following:
In order for OWSM to be invoked you need to attach the correct policies to the component within the Composite.
The policies we need are:
To attach these policies perform the following steps:
Once both policies are properly attached, you should see the following:
At this point the policies have been attached but they have not yet been configured.
OWSM needs to know (1) the URL of the OAuth server, and (2) where to get the Client ID and Secret. To provide this configuration information you must override the policy properties.
To do that, perform the following steps:
The dialog should appear as below:
The final step is to grant OWSM permission to use the credentials on behalf of the SOA Composite. This is also done via the EM console.
You should then see the following dialog box containing the current permissions for this policy:
Although it takes some setting up, utilizing OWSM policies makes it possible to invoke OAuth2 protected services via configuration rather than having to build the authorization process into the composite.