I recently read this blog post from Edwin Biemond where he explained how to configure SAML with OWSM using SOA and a JAX-WS webservice. I tried out the same using OSB projects and this post is to explain how to implement this in OSB.

First, some theory. SAML stands for Security Assertion Markup Language. As the name implies it is used to produce security assertions which can be passed between domains. Assume there are 2 domains – an Identity Provider domain and a Service Provider domain. The function of Identity domain is to authenticate users and systems through any standard authentication mechanism (e.g form based authentication for user authentication, ws-security username token for web service clients etc) and then produce assertions for the authenticated subject. These assertions , which are in XML format, are then passed to other domains ( service provider domains)  which trust the identity domain and hence the subject passed in the assertion. Thus the user will have access to the services produced by the service provider domain without re-authentication at the service provider domain thus enabling single sign on.

A typical usecase is when customers of a company access an external portal and perform some action on their customer account. While the portal provides a view for their account ,some of the functions they do will require interaction with the backend CRM system which could be a packaged application like Siebel. In this scenario , the sequence of interactions will be:

  • User logins to portal using a form based authentication
  • Portal authenticates the user against the enterprise identity store
  • If authentication is successful, portal can establish the identity of the user.
  • If user request some function on portal which requires CRM system access, the portal system then generates the SAML assertion for the established identity. The identity is stored in the subject field in the assertion. Portal makes a web service call to CRM system with the SAML assertion for the requested function.
  • CRM system gets the identity of the user requesting the function from the SAML assertion. [ Here identity means only username and not password] . This user should be  known to the CRM system. If the user has sufficient privileges to execute the requested function, it is executed and results are returned to the portal.

Thus the user was able to do a function on CRM system without doing a re-authentication thus enabling SSO. In this case the portal system acted as the Identity Provider domain and the CRM system acted as the Service Provider domain relying on the assertion produced by the Identity Provider.  But how can CRM system guarantee the assertion came from portal and has not been tampered with.After all, SAML assertions are plain XML and anybody could have produced it .

Sample SAML assertion

<wsse:Security soap:mustUnderstand="1" xmlns:wsse="">
    <saml:Assertion Version="2.0" ID="SAML-hs7rwRQI8G5o5ks5gJLIrA22" IssueInstant="2011-12-11T07:56:21Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">weblogic</saml:NameID>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
      <saml:Conditions NotBefore="2011-12-11T07:56:21Z" NotOnOrAfter="2011-12-11T08:01:21Z"/>
      <saml:AuthnStatement AuthnInstant="2011-12-11T07:56:21Z">

Digital Signatures are used to address this, where by identity provider (portal) signs the assertion using its private key and sends it public key in a x509 certificate along with the assertion in the request. At the service provider side there will be configurations to trust the certificate i.e. Service Provider domain should be configured to trust the CA which issued the identity provider domain’s certificate which contains its public key. There could be further configurations to restrict the acceptance of assertions like having a List of Issuer URI’s (one of the elements in the assertion)for SAML assertion and specific certificates to be used for signing the certificate. This is done by having a list of valid DN’s in the certificate that are authorized to sign the assertion.

Another terminology that comes up in the documentation is the SubjectConfirmation Method. The  above approach where the identity provider signs the assertion using its own key instead of using the users key is called Sender-Vouches as shown in the sample assertion above. Other method is holder-of-key where user’s certificate is used.

Now to our demo , we will have 2 OSB domains and projects for simulating the identity provider and service provider.

Step 1

Create  2 new domains called OSBClient Domain and OSBServer Domain.For simplicity select ‘Oracle Service Bus for developers’ in the domain configuration wizard. This will create an admin server only domains and you will need to run only 2 JVM’s to do this demo.

Step 2

Setup java  keystores for client and server domains using keytool.

Export client’s key from client keystore and import to server’s keystore, This will enable the server to trust the clients certificate at runtime

Export server’s key from server keystore and import to client’s keystore. This will allow the client to use the server’s public key to encrypt the assertion. In our demo, we are using a OWSM SAML with message protection policy. Message protection policy encrypts the SAML assertion beside signing the assertion.

It is confusing to visualize what keys and certificates are exchanged in scenarios like signing and encryption. Following note is useful to understand this.

when a client signs something and send to server, it signs with its private key and sends its public key in a x509 certificate along with the signed info in the request to the server. The server checks whether it trust the x509 certificate send by the client ,the CA issuing the client certificate should be present in the trust keystore of the server. Additional checks can be placed on the server side to test whether the client is authorised to sign that particular request. The server verifies the digital signature in the request using the public key of the client passed in the request.

When a client encrypts something and send to server, it generates a key for a symmetric  key encryption algorithm [ since symmetric key algorithms are much faster than assymetric key algorithms] , encrypts the request payload using the key and then encrypts the key using the server’s public key. The encrypted payload along with encrypted key is send to the server.The server decrypts the  key using its private key and then uses that key to decrypt the actual payload. In this setup, the servers certificate containing its public key is required to be present at client side.

Copy the keystoresto $DOMAIN_HOME/config/fmwconfig folder in each of the domains and rename the keystores to default_keystore.jks

Configure the OWSM agent keystore in each of the domain to use the keystore setup above. This configuration is done in EM console.

Step 3

Create a project called SAMLClient and deploy on OSBClientDomain. This project will be used to simulate the Identity Provider domain. It has one proxy service SAMLClientPS and a business service called SAMLClientBS.

SAMLClientPS is a any SOAP proxy service configured with an owsm ws-security username token policy. This is used for authenticating the client and establishing the identity.This proxy just routes to SAMLClientBS

SAMLClientBS is configured with a OWSM SAML with message protection policy.

In the security page of the business servce set keystore.recipient.alias to the server’s key imported to client keystore. This key will be used to encrypt the symmetric key used to encrypt the assertion.

Step 4

On the OSBServerDomain create a SAMLServer project. It has a SAMLServerPS proxy service configured with a owsm SAML Service with message protection policy. The proxy is any soap proxy service which returns a string in the response.


Test using OSB test console on the SAMLClientPS and see you can get the response back from the SAMLServerPS. Pass a owsm key containing an user in the client domain for ws-security username token authentication. In my case I just created a key in owsm for the weblogic user.

As seen in above screenshot the client PS was able to talk to server PS and get the string returned by it. The whole interaction works only when the ServerPS validates the assertion produced by the clientBS successfully, which in turn based on the identity established by the client PS using ws-security username token authentication. The user in the Subject field of the assertion should be present in the server domain for the SAML validation to succeed. The passwords for this user on the 2 domains need not be the same.  Other restrictions can be placed on the server like valid Issuer URI’s  ( our example uses default which can be overriden in the security tab of Client BS) and certificates for signing. These configurations which are done on EM console is demonstrated in Edwin’s blog link given at the beginning.

That’s all for now..


About atheek

I am a Weblogic consultant working in Middleware/Integration area.
This entry was posted in OSB, SAML, Security and tagged , , , . Bookmark the permalink.

15 Responses to SAML with OWSM in OSB

  1. Jesus Rios says:

    Very good Post thanks.
    I have a Question
    Where are you configuring that clientPS send the request to the serverPS???

  2. Marcin says:

    I am looking for info whether OWSM can be used in installation only with OSB. I mean if it requires SOA Suite to be present in installation in order to fullfil licensing requirements. There is OSB OWSM Extension but it is restricted use license?

    • atheek says:

      For all licensing matters it is best to confirm with the oracle sales consultant in your organization. I feel soa suite is not required but make sure to confirm with sales rep.

  3. Abhinav Gupta says:

    I am trying to simulate the same as above done by you ..
    i have created all the artifacts, but two domains(client and server) are not running at the same time( i have created two domains on the same system ).
    Domain started first works and second domain being started is being forced to shutdown .
    However both are running separately (if only is being is run on the system)..
    Please let me know what i am missing !!


  4. ymeng says:

    i have created the two osb domains. I don’t know why the “Policy” tab are not available. I can see the “Security” tab.

    Any idea what I have missed? in the domain config, i have “OWSM exentension”, EM, “OSB for developers”, “JAX-RPC extension”, and “WSM Policy Manager” checked.

  5. ymeng says:

    i think i figured it out. Policies tab will shows up for SOAP services. Thx!

  6. ymeng says:

    In the last bullet of “sequence of interactions” section, you mentioned that “This user should be known to the CRM system.” The CRM system in this case is the Service Provider.

    Based on my test, I can create a random user “foo” on OSBClient (Identity Provider in your example), this “foo” user doesn’t exist on OSBServer (Service Provider) at all, but OSBServer gladly trusts the request by user “foo” (which is vouched by OSBClient in the SAML assertion).

    Can you elaborate on how OSBServer uses the requesting user info? Maybe the user info is only useful in the case of authorization, because OSBServer already trusts the authentication from OSBClient.


  7. ymeng says:

    You may not want to show my previous post or this one. I think I mixed up my test cases ;-(

    “foo” user has to exist on the server, although it can have a different password. When I removed the policy on the client proxy, and the OSB/OWSM client simply generates an anonymous user like “owsm_anonymous_fe24daa0-bc21-4434-9d8e-148833612e92”, there seems to be some magic with the special anonymous user so the server always accepts it. Whatever user/pass I put in SOAPUI doesn’t even matter; they are irrelevant because the client PS doesn’t have any attached policy. It is interesting to see that the client still forwards the “irrelevant” wss name token to the server as-is, and the server PS ignores it just as the client PS does.

  8. raheem says:

    good post thanks

  9. Ravi says:

    Hi Atheek

    This is a wonderful post. I’m absolutely new to security, and this explained very clearly.
    I have a scenario where my OSB service is a pure passthrough. I have oracle/wss10_saml_token_service_policy at Proxy and oracle/wss10_saml_token_client_policy at BusinessService (with a credential key) side.
    Its working without establishing trust (importing keystore/certificate). Is it that for simple policies, trust is not required?
    I’ve expalined clearly in oracle forum

    Would you please chk it?


  10. Gaurav says:

    Thanks for the wonderful post. In given usecase I have a basic question regarding SAML policy.
    I tried to simulate same scenario but instead of OSB client domain I am using standalone java code.

    I have a OSB proxy with policy “wss11_saml_token_with_message_protection_service_policy” which I am invoking from a J2SE standalone WS client with policy “wss11_saml_token_with_message_protection_client_policy”.
    In client I have provided username, keystores and relevent everything and it works well. however I don’t understand the concept behind this how it worked.
    my question is – as far as I understand to get SAML token it needs to be authenticated first in an identity store. I am using username defined in weblogic default realm. but in this case where does that authN happen with weblogic when I make a call to OSB service. even it doesn’t need password ? and OSB proxy gets encrypted data. I understand encryption is done by private key. but when the user is authenticated ? or the policies I have applied above are only for encryption ? if that is the case why username is mandatory.
    Appreciate your response. It might be the very basic concept but somehow not able to figure out.

  11. Sanjay Bharatiya says:

    This is a really very helpful and informative post. Thanks a lot.
    I have a question related to this. Suppose on the server side there is a chain of Proxy Services (PS1 and PS2) to complete a particular business process. PS1 and PS2 are Synchronous. Say SAMLServerPS calls PS1 then calls PS2. PS1 and PS2 also have the same policies defined. How is the SAML token dealt with? For calling PS1 and PS2 separate SAML token is generated and passed or same token is used.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s