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:
- Create a keystore with the certicicate
- Configure keystore /credentials in Enterprise Manager
- Attach policy to service
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:
- 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.
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 oracle.wsm.security 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 oracle.wsm.security map in the credential store containing the alias and its password I want to use for my policy.
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.