1 Reply Latest reply on Apr 12, 2012 12:15 PM by Jamie Adams

    OWSM - using x509 policy for Client Certificate Authentication

    Jamie Adams
      Hi All,

      Apologies in advance for the long post, but I have a complicated issue with OWSM.

      We have been trying to use OWSM in order to authenticate a request when calling an external API via certificate authentication (using a customised wss11_509_token_with_message_protection_client_policy), but have been having some difficulty in doing so.

      We are making calls to the API via SOAP requests through OSB, the idea being that we attach the relevant policy to the Business Service when invoking the Service Callout.

      In this case scenario there are 2 layers of security.

      Firstly, a custom 'RequesterCredentials' element is required in the soap header including a username and password (not the standard wsse username and password).
      Secondly, we want another layer of security where client certificate authentication is required.

      I have configured a java keystore using the certificates given to us by the client, for use with OWSM. I believe there are no problems with this keystore as if I test the API via a different client (SOAPUI), configured to use the same keystore along with the relevant 'RequesterCredentials' in the SOAP Header, then we get a successful response.

      I have then taken the following steps:

      - Imported the keystore to ..config/fmwconfig directory.
      - Configured the keystore in the Security Provider Configuration section of Enterprise Manager.
      - Configured the Security Credentials in Enterprise Manager.
      - Imported a a different client SSL certificate to the truststore, so we get past the SSL handshake with the client.
      - *Customised the wss11_509_token_with_message_protection_client_policy.

      * It is at this stage that I have the problem. The request we send does not need to use a lot of the settings enabled in this policy. We do not need message protection so the encryption is disabled. We will handle the SOAP Header configuration in OSB so the unnecessary header elements (addressing) have been removed from the policy.

      I assume all that we need is WS-Security 1.1 Mutual Auth with certificates enforced.

      If I associate this policy to the business service making the call (and apply the relevant credential overrides), when I test I can see the request being sent has lots of additional security elements added to the SOAP Header (some of which look encrypted which makes me believe that the keystore is configured correctly), in the form of Binary tokens/ digital signatures etc, and the request fails due to a 'soapenv:MustUnderstand' error (an attribute on the WS Security added to the SOAP Header).

      If I UN-enforce this in the policy then the request is made and we get an authentication/authorisation failure response from the client (as if the policy is not associated with the certificate in the keystore any more).

      I think that 'MustUnderstand' error is a result of the addition SOAP Header elements being added that the consuming API is not expecting.

      I am not a security expert and the client has simply told me that I need to 'present' the client certificate along with the request (including the 'RequesterCredentials' Header) making the call.

      My assumption is that x509 policy is the right one as none of the other descriptions seem to match...

      Am I missing some step here, or can anyone give me some advice on where they think this might be going wrong?

      On a side note I read that you can create custom policies by copying current oracle security classes and extending these. However, would like to avoid going this low level if possible, as I would have though simple client authentication via certificate would not require this?

      Any input appreciated.

      Many thanks,


      Edited by: 920251 on 13-Mar-2012 07:47

      Edited by: 920251 on 13-Mar-2012 07:48

      Edited by: 920251 on 13-Mar-2012 07:49