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="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<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:Conditions NotBefore="2011-12-11T07:56:21Z" NotOnOrAfter="2011-12-11T08:01: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.
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.
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.
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.
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 http://www.oracle.com 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..