Invoking WebService Over SSL From SOA

This again is one of the topic for which you will find lot of blogs and article that tells different steps to invoke a webservice over SSL. Some mentions adding a certificate in default-keystore.jks, some says about adding the certificates in cacerts.jks and others about enabling JSSE SSL. Basically confusion all over the place which one is correct and which step is irrelevant.

And so I decided to try it out and explain each of the step why it is required. Lets start then -

1. First you will be given a webservice or wsdl url which looks something like this -
https://abc.xyz.com/soa-infra/services/default/CreateAdvancedElectronicInvoiceSignatureReqABCS/CreateAdvancedElectronicInvoiceSignature?wsdl

2. To retrieve the certificate open this url in a browser say in IE. Click on a lock icon and then click on view certificates. Goto certification path. That will show the entire certificate chain usually like this -
       Root certificate
          SubCA certificate
             LB/Server cerrtificate

3. Export each one of them by selecting and View Certificate > Details > Copy to File. Save them in "DER encoded binary X.509" format.

4. We are going to import all the certificates in WebLogic truststore because its a public key that we are importing as a trusted certificate which will be sent by WebLogic to the host server to establish SSL connection.

5. By default WebLogic uses DemoTrust.jks which can be found on /opt/oracle/middleware/wlserver_10.3/server/lib/DemoTrust.jks. Some blogs talks about importing certificates in cacerts or default-keystore.jks. But this is not required because cacerts is a java keystore and when weblogic has its own separate trust store then why to mix the things. Further default-keystore.jks is used to store the certificates required for message encryption and digital signature.

6.Import all the certificate in DemoTrust.jks as trusted certifcates using the command
keytool -importcert -alias ikeadt -trustcacerts -file /u01/deployment/Root.cer -keystore DemoTrust.jks

7. Next enable JSSE SSL from admin console for the SOA managed servers and then restart. JSSE is to allow WebLogic to support stronger cipher suite and MAC algorithm. If JSSE is not enabled then WebLogic will throw error - FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received.

8. Finally add the credential key under credential maps from EM console. The key name must be same as what used in csf-key value. Enter user name and password that will be used for authentication.

By following all the above steps you should be good to invoke a webservice over SSL. If there are question and queries or something you found not correct then shout out in comments !

Load and Scalability Testing of Web Services

Load and performance testing of services are critical part of SOA integration but given less importance in most of the projects. Oracle SOA EM console has capability to perform basic stress testing where number of thread and other parameters can be configured. But when it comes to testing with large xml messages or monitoring the load test, a need of separate testing tool arises.

Many good web service testing tools are available in the market and some of them are free as well. I personally like soapUI for load testing as it easy to use, has predefined test strategies and most importantly available free. Recently I got involved in a performance testing of a service with large xml payload, as big as 60MB. I tried copying the 60MB payload and pasting it in soapUI but it stopped working. I left with no other option but to look for other simple testing tool that can support large xml payloads and quick to use. I wish soapUI had given a feature to read the payload from the file.

While hunting for such testing tool I came across "WebInject" tool that has a pretty basic UI but supports large xml payload as well. Its easy to use and configure and you can be ready with your test case in few minutes.

Just write your test case in xml file as shown below and add your test case to config.xml. Done !

<testcases repeat="1">
<case
    id="1"
    description1="Testing big invoice with 4K lines"   
    method="post"
    posttype="text/xml"
    url="http://server.host.com:8001/soa-infra/services/default/Orchestration/Report_ep"
    postbody="file=>BigInvFromITM.xml"   
/>
</testcases>

Removing Files & Folders from SOA MDS

There are scripts available over internet to remove the artifacts from MDS. But there are couple of other methods as well to achieve this without using script. And they are -

Remove entry from MDS_PATHS table -
Connect to SOA_MDS and search the table MDS_PATHS. This table holds the information of all the folder that are registered in MDS. Deleting an entry from this table will remove the artifact from the MDS as well. But the catch with this method is even if you remove the entry in this table there are various other related tables where the entry will still exist.

WLST deleteMetadata method -
WLST has deleteMetadata method that can be used to delete the file/folder from the MDS. It can be done through command line or from EM console as well.

Doing it command line way -

run (UNIX) MIDDLEWARE_HOME/ORACLE_SOA1/common/bin/wlst.sh

offline>connect('user','password','hostname:7001')
wls:/soa_domain/serverConfig> deleteMetadata(application='soa-infra',server='soa
_server1',docs='/apps/wsdl/*')

Executing operation: deleteMetadata.

Operation "deleteMetadata" completed. Summary of "deleteMetadata" operation is:

List of documents successfully deleted:
/apps/wsdl/test.wsdl

1 documents successfully deleted.

Doing it via EM console -

Right click soa-infra and goto MDS configuration as shown in image below.

 

 select "Runtime Configuration"

Then goto operations and click deleteMetadata.

Edit the docs and provide the similar arguments as shown in command line and click invoke. That should remove the folder as passed in the argument.

Tutorial - Service And Client using ws11_username_token_with_message_protection Policy

OWSM comes with pretty extensive list of pre-defined security policy to serve the security needs in SOA and integration domain. These policies can be attached to a service or client as required and the actual implementation remains unaffected.

There are some documents, pages available about how to secure a SCA, bpel and how to write a secured client using "ws11_username_token_with_message_protection" policy but most of them are in bits and pieces. Hence I decided to write a tutorial with step by step information so that one can find all the steps and details at one place. Please go through it and shout out (by commenting :) ) if you see any step missing.

But before we start first understand what ws11_username_token_with_message_protection policy offers. This policy follows WS-Security 1.1 specification to apply authentication and message protection for a given. For authentication credentials (username, token) are passed in plain text and the message is protected by encryption and digitally signing the message.

Securing a service with ws11_username_token_with_message_protection_service_policy

Pre-requisite: A SCA with a bpel. An authentication provider must be configured on the weblogic and it should be first in the list of providers with "SUFFICIENT" control flag.

• Open the composite and right click on the exposed service. Then select "Configure WS Policies".
• Select the request binding from drop down (top) in the window that appears.
• Under "Security" section click add button and select "ws11_username_token_with_message_protection_service_policy".

Next step is to setup Oracle WSM keystore with private keys and configure server to support the message encryption and digital signature of the message.

• Goto <domain_home>/config/fmwconfig
• Create a JKS keystore with keytool or any other UI based tool like "KeyStore Explorer". This keytool command below will generate a self signed private key for encryption and digital signature and create a keystore if it doesn't exist or else add it it existing keystore.

keytool -genkeypair -keyalg RSA -alias myalias -keypass welcome2 -keystore default-keystore.jks -storepass welcome1 -validity 3600

• Next open the EM console, expand Weblogic Domain and right click on domain.
• Navigate to Security > Security Provider Configuration 

• Expand Keystore and click Configure button.

• In next page enter the Keystore path, password, Signature Key Alias, Encryption key Alias and password. From above command the signature, encryption alias and password will be myalias and welcome2 respectively.

• Restart the server.

Verification - The service wsdl should be changed now to include the security policy.

Configure a client with ws11_username_token_with_message_protection_client_policy

• Open the composite and right click on the exposed service. Then select "Configure WS Policies".
• Select the request binding from drop down (top) in the window that appears.
• Under "Security" section click add button and select "ws11_username_token_with_message_protection_client_policy".
•  In client's keystore import the server certificate if a self signed certificate is used. If CA issued the server certificate then import the root certificate from CA to client truststore. Below command export the certificate from the server keystore.

keytool -exportcert -alias myalias -file root.cer -keystore default-keystore.jks

 -storepass welcome1

• And this one import the server certificate (public key) into client keystore with the alias provided.

keytool -importcert -alias svrcrtalias -trustcacerts -file root.cer -keystore 

client-default-keystore.jks -storepass welcome1

With above steps the client's keystore is configured to use the server's public key for encryption and signing the message. The username token policy that we attached in first step needs a username and credential to pass. But from where does this username, credentials will come ? This info will come from the password store in OWSM CSF (Credentials Store Provider). Follow the below steps.

• Open the EM console, expand Weblogic Domain and right click on domain.Navigate to Security > Credentials.

• Under map oracle.wsm.security, create a new key with the name you like for e.g. com.sample.test
• Provide the username, password and press ok.

Now the policy should be pointed to use this credential. Follow below steps to achieve this.

• Goto JDeveloper and open the composite having the reference of the secured service.
• Right click and select "Configure WS Policies".
• Select the pre-attached client policy under security section and click the edit icon. The window will show up like below.

• Edit the csf-key and enter the key name of OWSM CSF which in our case is - "com.sample.test". 
• Edit the keystore.recipient.alias and update it with the alias that was provided while importing the server certificate in client keystore. In our case it is - svrcrtalias. It is an indication to the client weblogic to use certificate corresponding to given alias for encryption and signature of messages.

 This completes the client configure to invoke the service secured with username token authentication, message encryption and digital signature.

Oracle SOA Suite 12c Released

Oracle recently released the 12c version of SOA suite. Some of the key features included in this release are -

Adapter for cloud integartion for e.g. SalesForce.com
REST/JSON support for mobile application integration
MFT or Managed File Transfer that provides security, resubmission & large file support!
JDeveloper is now an integrated development environment for SOA & OSB both!
It has ESS for our scheduling and triggering requirements !
BPEL can now transform message using XSLT or XQuery !
Error Hospital that happened to be in 10g is back again in its revamped format.

Yet to explore more on 12c like whether OSB now support MDS or not, performance and monitoring capabilities of Enterprise Manager etc.

Xquery or XPATH to check for the existence of element

This is a very common validation in BPEL or OSB to find  if an element or child element exist in xml or not. In OSB there are xquery function like fn:exists() can be used to achieve this. But in BPEL there is no direction function available to check for the existence of element. So here is an alternate way to do that. The xpath function countNodes can count the number of nodes present in the element or under that element as child element.

ora:countNodes('inputVariable','payload','/ns1:process/ns1:File/ns1:Content/ns1:XMLContent/*')>0

Note the first parameter in the function which is variable name and the value is 'inputVariable' instead of '$inputVariable'. The function accepts only variable name as parameter.

Second is part name and third one is the exact path after part name.

The above function is used to find out if the anytype element 'XMLContent' has any child elements or not. The schema is below -

Another way to use (see SAARequester) countNode is this -

ora:countNodes('saaVar','ns4:Body/*')=0

where saaVar has no part name and it has this structure -

Best Practices While Connecting to Weblogic 10.3.x JMS from Hermes

Based on my experience it is good to follow below rules to avoid annoying errors/exception and consequently save your time.

1. Do not create a provider by adding weblogic.jar, instead create wlfullclient.jar and then add it as a jar in your provider. From weblogic 10 onwards this is the procedure.
2. Preferably create a wlfullclient.jar from the server instance where you want to connect. That way you can avoid any version and class not found issues.
3. Note the port of T3 url. It is the listen port under servers on admin console. If you are connecting to a server with soa suite then the server to check is the managed server i.e. soa server. Usually the listen port for soa server is 8001. In this case t3://<hostname>:7001 will not work.
4. If a server is behind the firewall then the port needs to be opened in firewall for communication to work properly.

Certificates, CA and Certificate Chains

I came across a really good document from Oracle on certificates and security related topic. Below is the link -

https://docs.oracle.com/cd/E19656-01/821-1507/gdzeb/index.html

Pasting here some of the contents in case the url changes or goes away.

Certificates - A certificate is an electronic document that identifies an individual, a server, a company, or some other entity. A certificate also associates that identity with a public key. Like a driver’s license, a passport, or other commonly used personal IDs, a certificate provides generally recognized proof of someone's or something's identity.

Certificate Authority (CA) - Certificate authorities, CAs, validate identities and issue certificates. CAs can be independent third parties or organizations that run their own certificate-issuing server software. The methods used to validate an identity vary depending on the policies of a given CA. In general, before issuing a certificate, the CA must use its published verification procedures for that type of certificate to ensure that an entity requesting a certificate is in fact who it claims to be.

Any client or server software (like browser) that supports certificates maintains a collection of trusted CA certificates. These CA certificates determine which other certificates the software can validate, in other words, which issuers of certificates the software can trust. In the simplest case, the software can validate only certificates issued by one of the CAs for which it has a certificate. It’s also possible for a trusted CA certificate to be part of a chain of CA certificates, each issued by the CA above it in a certificate hierarchy.

CA Hierarchy - In large organizations, it may be appropriate to delegate the responsibility for issuing certificates to several different certificate authorities. For example, the number of certificates required may be too large for a single CA to maintain; different organizational units may have different policy requirements; or it may be important for a CA to be physically located in the same geographic area as the people to whom it is issuing certificates.

Certificate Chains -

A certificate chain traces a path of certificates from a branch in the hierarchy to the root of the hierarchy. In a certificate chain, the following occur:

• Each certificate is followed by the certificate of its issuer.
  
• The Engineering CA certificate contains the DN of the CA (that is, USA CA), that issued that certificate. USA CA’s DN is also the subject name of the next certificate in the chain.
  
• Each certificate is signed with the private key of its issuer. The signature can be verified with the public key in the issuer’s certificate, which is the next certificate in the chain.
  

In image above the public key in the certificate for the USA CA can be used to verify the USA CA’s digital signature on the certificate for the Engineering CA.

Powerful Xpaths

XPATHs are powerful way to traverse and query the xml documents. I am listing here some of the useful xpaths and their meaning to keep it handy.

purchaseOrder - select all nodes with the name purchaseOrder
/purchaseOrder - select the root element purchaseOrder
/purchaseOrder/items - select all item elements that are children of purchaseOrder
//items - select all items elements irrespective of their locations in the entire document
purchaseOrder//items - select all items child element of purchaseOrder irrespective of their location under purchaseOrder element.
/purchaseOrder/* - select all child nodes of purchaseOrder element.
// - select all elements in the document
/purchaseOrder/items[last()] - select the last items element of purchase order.
/purchaseOrder/items[position()<3] - select first two items child elements for purchaseOrder
//items[@partNum] - select all elements that have attribute name 'partNum'
//items[@partNum='123'] - select all items elements that have attribute name 'partNum' having value 123
/items/item[price>300] - select all item element under items that have 'price' element with value greater than 300.

Oracle SOA Starts Slow On Linux

Recently I encountered one strange issue while running Oracle SOA server on Oracle Enterprise Linux. Start script of admin server (startWeblogic.sh) halts on this command -

java -client -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n -Djava.compiler=NONE  -Xms1024m -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=786m -Dweblogic.Name=AdminServer ..........................................................................................................
............................................................................................................................................................

After lot of googling I found a solution. This page has details to resolve this issue and I am including a link here to refer it easily in future and for others to find it quickly.

http://www.itonguard.com/20090313/weblogic-starts-slow/

Solution that I used and it worked perfectly is -

1. change $JAVA_HOME/jre/lib/security/java.security
2. Replace securerandom.source with

             securerandom.source=file:/dev/./urandom

Authentication Provider Control Flags

Multiple authentication providers can be configured to weblogic server. Their precedence/order and participation in authentication can be defined using control flags. Weblogic provides 4 types of flag and there meaning may look ambiguous if you go by their name. Here is the definition of control flag for the sake of record.

REQUIRED: This option is the default setting for any Authentication Provider. A required Authentication Provider is always invoked, irrespective of the control flag settings on other providers. The overall authentication cannot succeed if any REQUIRED provider fails. Thus, REQUIRED providers are always invoked, and overall authentication fails if any one of them fails.

REQUISITE: This option also requires the Authentication Provider to succeed during the login sequence. However, all of the REQUISITE providers need not be invoked for the overall authentication to succeed. If a REQUISITE provider succeeds, the authentication proceeds as normal to other providers in the sequence. However, if it fails, the overall authentication cannot succeed, and control is immediately passed back to the application once all REQUIRED providers in the login sequence have been invoked.

SUFFICIENT: This option does not require the Authentication Provider to succeed during the login sequence. If a SUFFICIENT provider does succeed, the overall authentication proceeds to ensure that only the remaining REQUIRED providers in the login sequence are executed. However, if it fails, the overall authentication proceeds as normal to the other providers in the login sequence.

OPTIONAL: This option does not require the Authentication Provider to succeed during the login sequence. Regardless of whether an OPTIONAL provider succeeds, the authentication proceeds to other providers that have been configured as part of the login sequence.