How to configure SAML in Oracle Service Bus (OSB) 12cPublished on: Author: Eduardo Barra Cordeiro Category: Oracle
How to configure SAML in Oracle Service Bus (OSB) 12c and tracing your messages? I'll show you in this blog.
And how to trace issues?
During projects that requires integration with service providers (usually third parties) it is quite common to use security, authentication and/or message sign in the form of encryption to exchange messages between a trusted client and a trusted provider. In this post I will describe how to configure and implement these within the Oracle Service Bus 12c, showing some differences between OSB standards policies types and how to trace them in the diagnostic server log. I assume that you have experience in OSB, but not too much experience in how to setup security.
Keep in mind that the scope in this blog will cover only some parts on OSB level. Check in your case what are the requirements and possible restrictions in your network. For example, a proxy and firewall configuration can have some additional attention needed. Usually when you have a third party involved, you will have to need to whitelist your service provider endpoint to be able to connect to it and your client must have done the same to receive your connection.
In this post I used a pre-built standard 12.2.1 VM provided by Oracle, containing WebLogic, SOA Suite, OSB and JDeveloper. You can find it here.
1. Setup WebLogic to support SSL
Configure WebLogic (WL) to support SSL will enable HTTPS port and security connections to your server.
How to do that?
First of all, we will create a custom identity JKS, a custom trust JKS and configure a self-signed certificate.
- Open a terminal to connect in your server box.
- Find in your server directory the folder security. If you are using the suggested Oracle VM go to < path to your domain directory for security artefacts; example: /u02/oracle/fmw/config/domains/soa_domain/security/
- Execute the commands below to create your keystore. It will generate the private/public keys (example: identity.jks file). You can change/adapt the name and password if needed. Keep in mind that during the post I will use the below parameters.
- This script will require some information from your company. Inform it as need. One of them will be Common Name and you should provide a domain/DNS/machine name. Usually in real production systems where we implement our own keystores, the CN should match your domain name.
- keytool -genkey -alias myidentity -keyalg RSA -keysize 1024 -validity 365 -keypass identity1234 -keystore identity.jks -storepass identity1234
- Now export the public key based on your identity just created. To do that execute this line:
- keytool -export -alias myidentity -file root.cer -keystore identity.jks -storepass identity1234
- The next step will be import your public certificate in your trust.jks file. It contains all trusted certificates in your WL server. You need to add to this file all trusted certificates that you supposed to connect with. Execute the follow line:
- keytool -import -alias myidentity -file root.cer -keystore trust.jks -storepass identity1234
- Now open the WL console and go to Server/Configuration/General tab of a managed server. Check if SSL Listen Port is selected and obtain the configured port.
- Now move to Keystores tab. In the first option select Custom Identity and Custom Trust. We will setup using the files that we just created.
- You need to give in the path for identity.jks and trust.jks. Also, you need to give in the keystore type (JKS) and the password used in both keystores creation.
- Save the changes and move to tab SSL. There you need to inform your private key alias and the password.
- Save the changes once again. In the same tab, click on Advanced. In Hostname Verification select the option None. We need to select it if the Common Name of the certificate is not the same as the hostname of the machine where WLS is installed.
- Save your changes.
- At this point you will need to restart your server to apply the changes you’ve implemented.
- When the server is back you are able to access your WL console using http or https. If you applied the changes in the correct way both will work for you:
- In the https you will be able to see a lock:
- More details about this configuration, SSL and self-signed certificate creation are available in these articles: here and: Doc ID 1109753.1
- Be aware that in many organisations self signed certificates are only used for test purposes and not allowed in production environments.
2. Configure OWSM security
The next step will be: setup the credentials that will be used in SOA and OSB context. The keys will be used together with policies set in the code.
How to do that?
We will use the EM to create the credentials and map them on WL domain.
- Open the Fusion Middleware console (EM). Locate your SOA domain, Security, Credentials.
- We will create now 3 keys, as you can see below. For each one use your private key alias as been used previously and password (that will be myidentity/identity1234 if you are following these instructions). Each one will be used for a different action. In this sample we are using the same private key in all of them. Consider that you can use different certificates for signature and encryption, for instance.
- Now go to Webservices, WSM Domain Configuration. There we will configure the credential keys just created.
- In Keystore Configuration/Path set the identity.jks path.
- In Signature Configuration select the key just created for this context.
- In Encryption Configuration select the key just created for this context.
- Save the changes.
3. Deploy the test code
- Click on the red button below to download a zip file with the HelloWorld projects that I created in this sample. It is quite simple usecase: one BPEL composite with policy defined (service provider) and one OSB project that will call the BPEL project (client) with the same police configured. We will simulate some scenarios to validate different OSB standard policies, starting with wss10_saml_token_with_message_protection.
4. Enabling OSB log tracing for troubleshooting proposal
Before proceed with policy validation I will show how to enable the trace in OSB 12c. On code level we are already able to include log activities in pipelines. In server side we can enable the tracing for business services as well. This is important for debug and troubleshooting. OSB provides a good feature to show how the exact message is generated, including the security header, when a business service calls a service provider.
How to do that?
Follow the steps below to enable the tracing:
- In the Fusion Middleware console (EM) open the ServiceBus console.
- Let’s check what is the current OSB diagnostics log level. You will need to set it at least to “Notification” to have the proper level of information logged. By default, oracle.osb is set to “Warning”.
- Back to ServiceBus dashboard, click on Operations. Them click on search to show all your projects.
- You will see in this page all activities that can be traced. Select in Message Tracing column what are the operations that you want to trace and click apply.
- For each object you will have different trace level. By default, OSB sets Terse. It is not enough if you want to show all the traces in the diagnostic log file. Select Full.
- Also, keep in mind that the default size 8,192kb is too small if you are planning to use encryption. Prefer to set it over 30,000kb just in case. Otherwise your messages will appear cut in the log.
- Those are the needed steps to start see your endto-end flow logged in diagnostic.log. Remember to disable the trace when you are done with your debug and/or troubleshooting.
5. Policy validation
In this step we will use some different kind of standard policies provided by OSB and see different setups and results.
How to do that?
First, be sure that you deployed the code available in session 4. After deployment we will update the policy using the EM and ServiceBus consoles. Follow the steps below:
- Check if you already have your code deployed (BPEL and OSB).
- Check if you have in BPEL project the service policy set: wss10_saml_token_with_message_protection_service_policy
- Now check if you have the correspondent client policy set in your client OSB:
- In this case we are using the following parameters to set the client policy. Each policy will require different mandatory information, based on what kind of envelope will be generated. In this example we will sign, encrypt and authenticate:
- keystore.enc.csf.key: enc-csf-key
- keystore.sig.csf.key: sign-csf-key
- csf-key: keystore-csf-key
- keystore.recipient.alias: myidentity
- Configure your client service in SOAP and drop a new request.
- If you followed the step before (4 Enabling OSB log tracing for troubleshooting proposal) you will be able to see in diagnostic.log server log the payload generated with all required header information in client side. Also, you will see your body encrypted.
- Besides, will you have the response received from your service provider, including all required information as well such as an encrypted body.
- Click on the red button below to download the two xmls with a sample message generated for request and response.
- Now we will change the policy and see different results in the log.
- Let’s start changing the service provider policy. Go to EM and open the BPEL project in the policy tab.
- Click in Attach to/Detach From and select HelloWorldWithSAML
- Select wss10_saml_token_with_message_integrity_service_policy and click Attach.
- Select the previous policy and click in Detach. Click OK.
- Before changing the client side, test using SOAPUI the same request. Now you should receive an error:
- In this example I am not using error handling at OSB code level. In the log you will see the reason for this error:
- [date-time] [soa_server1] [ERROR] [WSM-00279] [oracle.wsm.resources.security] [tid: [ACTIVE].ExecuteThread: '15' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: bf7525a0-5a35-4bfa-878a-5498596331be-00001b0e,0:3] [APP: Service Bus Kernel] [partition-name: DOMAIN] [tenant-name: GLOBAL] [FlowId: 0000MGIFTNPFw000jzwkno1R8w1Q00000N] [oracle.wsm.policy.name: oracle/wss10_saml_token_with_message_protection_client_policy] The following Fault Message is received at the client side from the service:- [[InvalidSecurity : error in processing the WS-Security security header. The client side policy is:- oracle/wss10_saml_token_with_message_protection_client_policy.
- NOTE: checking the logs will be always a good way to understand your error messages.
- Now let’s change the client side and check again.
- Open the ServiceBus console, create a new session and locate the ServerWithSAML Business Service that will be updated with the correct policy: wss10_saml_token_with_message_integrity_client_policy
- The mandatory parameters for this policy will be different, since they are not required for this encryption:
- keystore.sig.csf.key: sign-csf-key
- csf-key: keystore-csf-key
- Activate the session and try a new request using SOAPUI project. It should work fine now.
- Now let’s see what has been generated in diagnostic.log file. This is the outbound message sent from OSB client to BPEL:
- And here we can see the response:
- Note that the body this time is not encrypted and the response header is much simpler.
- Depending on the requirements you can use different policies, including tokens. Oracle provides a lot of information about it. You can see the different scenarios in the articles below:
- It is not common but you might need a customized policy to adapt the service provider requirements. Read more here: https://docs.oracle.com/cd/E28280_01/admin.1111/e15867/policies.htm#OSBAG933
- Securing your webservices is a usually a requirement at customers.
- The standard OSB policies will help you to have implement exact what you need.
- In case your service provider does not use OSB or OSB policy standards you will need to customize yours.
- Using the log tracing you will be able to know what message has been sent in case you need to troubleshooting the transaction.