Using OWSM x509 token client policy with OSB 11gR1 PS3

Izaak de Hullu 3
0 0
Read Time:5 Minute, 43 Second

Since 11GR1 Oracle Web Service Manager (OWSM) has been integrated with the SOA Suite. This means you can easily attach web service policies for security and management to your SOA Suite artifacts. In this post I will explain how to attach a x509 client policy and do the configurations  to get it actually working. This policy is the implementation of the OASIS Web Services Security X.509 Certificate Token Profile 1.1.

In short the configuration with consist of the following steps:

  1. Create a keystore with the certicicate
  2. Configure keystore /credentials in Enterprise Manager
  3. Attach policy to service
  4. Run

First we will create a keystore with a key pair (self signed certificate) in it. You can do this very easily with keytool.

keytool -genkeypair -keyalg RSA -dname “cn=sao-host.domain.local,dc=amis,dc= dc=nl” -alias signkey -keypass welcome1 -keystore testkeystore.jks -storepass welcome1 -validity 1064

There are other ways to create this. In some blog I read you have to create a certificate with the SubjectKeyIdentifier extension. You can only do this with openSSL. But in some other posts I have read openSSL certificates will not work. So confusion all over the place. For me creating the certificate this way worked. Especially for testing purposes this is sufficient.Â

In the above command I highlighted the parts you need to remember. We need them later when we configure the keystore in EM and the policy in OSB.

Secondly comes the tricky part. Tricky in it is very badly documented and there are no examples. The documentation is scattered around the place and not very coherent. So it took me some time to figure this out.  You can see everything around security in Enterprise Manager is still in a transition phase. Parts of the security configuration are still in weblogic, parts can already be done through Enterprise Manager. This makes it somewhat confusing what to do where. The configuration of this particular OWSM policy can all do inside Enterprise Manager.

The directory DOMAIN_HOME\config\fmwconfig  is a very important directory for the configuration of security in Enterprise Manager. First we need to copy our keystore to this location. Amongst other files this directory now contains the following two important files:

  1. cwallet.sso
  2. testkeystore.jks (you have to copy the earlier created keystore to this directory)

cwallet.sso is the file based credential store used to store domain wide credentials. We will store credentials we need to get the policy working inside here later. testkeystore.jks is the keystore we just moved here.

First we make sure that EM/WSM will use the keystore we just created. So browse to the Security Provider Configuration and configure the keystore.

Press on the Configure button.

We need to set some defaults for the signature key and encryption key. This is mandatory. You can just enter some values , they do not have to exist inside the keystore as they are not checked here. When we later on execute the policy with a particular signature key we can be sure it uses this one and not the default configured one.

So what do we need to configure next? Before we continue I will first explain how OWSM policies, the keystore and the credential store work together.

If we take a look at the policy we are going to use we see three configuration properties of which  keystore.sig.csf.key is the most interesting one for use. We will only use signing. This key is by default mapped to the sign-csf-key key inside the credential store in the map. So when the policy is executed it will use the username and password belonging to this key to retrieve the actual private key from the keystore to create the signature. It will use the username as the alias.  The keystore itself is protected with a password that is stored under the keystore-csf-key in the credential store. A dashed line means a default mapping. Â

This is the default behavior. You can add your own csf keys to the credential store to map to different aliases in the keystore. Now you have the possibility to use multiple certificates instead of just one default one.

You can do the assignment of another csf key in multiple places. When you create a copy of the policy inside EM you can set the value of the keystore-sig-csf-key to your own key name. Or you can do it when you attach the policy to the OSB service inside OEPE or when you have deployed the service inside the OSB console.
I my case I do not want to use the defaults. So I add an additional key to the map in the credential store containing the alias and its password I want to use for my policy.

I named it my. csf.key and filled in the alias signkey as  the user name  and welcome1 as the password.

The final step is to attach the policy to the OSB Service. I want to attach the policy to a business service. I need to select a service client policy in that case.

To attach the ws11_x509_token_with_message_protection_client_policy to my OSB service I make a version of an existing policy for my own use. I do not want to use any  encryption and I want to sign some additional headers instead of the default ones (WS Addressing headers only) . Otherwise I could have used the out-of-the-box policy.

I Changed the policy name and unchecked the encryption of the body on both the request and response. Furthermore I removed the ws addressing header signing. After this I saved the policy.
Attaching this new policy to your Business Service is very simple. On the policy tab of the business service I selected OWSM Policy from policy store. Then you can Add the policy by browsing the policy list that is retrieved from OWSM (Mds Store). Make sure you attach the OSB Configuration Project to your server first otherwise you get an error no server can be found to retrieve the policies from.

Now when I have deployed the OSB project I can browse to the service and set the correct signing key. So press Properties and the window below will be opened Enter my.sig.csf.key as the value for keystore.sig.csf.key and enter signkey as override value for keystore.recipient.alias. This alias is used to retrieve the  public key to encrypt outgoing messages.  Somehow this property is mandatory so we need to provide a valid value as it is being checked. Â

Well that’s it…. When you test the service inside the osb console you will see the request is signed.

About Post Author

Izaak de Hullu

Izaak de Hullu is an architect SOA and Integration. Experience in mostly Java integration projects with products like OSB, Weblogic but also BPM/BPEL products like Oracle BPM en Cordys.
0 %
0 %
0 %
0 %
0 %
0 %

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

3 thoughts on “Using OWSM x509 token client policy with OSB 11gR1 PS3

  1. What does it mean when you talk about ClientID/password authentication. Do you want HTTP Authentication or  username/pass WS Security? That makes a difference…

    Loading a certificate in a keystore is not enough to sign/encrypt your service. You need to configure and attach the right policy otherwise nothing happens.   The above post explains the encryption and signing part. Depending on what you mean with username/password authentication you need to do additional things.

  2. From Fusion 11g SOA composite, I need to call  external 1099 web services. These  are secured with two-factor authentication consisting of a trusted X.509 certificate and a client ID and password credential set. And it needs this Client X.509 certificate to generate a signature based on the SOAP header contents, which is then verified by server.
    I have done the following so far: I created a self signed X509 cert on the SOA server, loaded it in a keystore and set up the credentials in weblogic domain. When I test my service, I do not see the message signed and encrypted. Can you please help me with the steps I need to do?

  3. Hi, thank you for your excellent blog post.  I simply cannot find the place to ‘override properties for policy’.  I made a copy of the policy to be used on my client (ws11_message_protection_client_policy).  Also managed to configure keystore using Security Provider configuration in  Enterprise Manager.  Client and Service are SOA projects deployed on two different WebLogic servers.  Although keystore is loaded successfully,  I get this error when running the client:
    … Configuration property keystore.enc.csf.key value is null
    [soa-infra] Successfully loaded keystore [ path:C:\Oracle\client\default-keystore.jks, type:JKS, sign-alias:orakey, crypt-alias:orakey, recipientAlias:orakey, recipientCert:null]
    …. testdigitalsignature_client_ep] [ soa-infra] [arg: java.lang.NullPointerException] WS Binding: exception durign SOAP invocation: java.lang.NullPointerException
    Any help is much appreciated,

Comments are closed.

Next Post

ODTUG Kaleidoscope 2011 - The Premier Conference for Oracle Fusion Middleware

My favorite conference since 1997 has been the yearly ODTUG [Kaleidoscope] conference. Because of its size – that lends an intimacy to the event that is simply unique – and the way the program is structured – with a perfect mix of content and more playful activities – as well […]
%d bloggers like this: