Some useful stuff !

Some useful stuff which I use as a reference for work.

Process Listening at a Port (Windows)

Have you ever felt the need to know which process is listening at a particular port on a windows machine? The windows version of netstat has a cool option to do this[ “-O”], similar to what lsof (lsof -i : port number ) can provide in Unix.

C:\>netstat -nao| find “LISTEN”

The last column gives the id of the process listening at the port. Process 1756 above is the Filezilla ftp server which listens to the ftp port 21.

To view the process name just hit ctr+alt+del and select task manager.If PID column is not available in task manager then go to View –> Select Columns and check PID.

This will be useful if you want to kill a particular instance of weblogic server , when you have multiple servers running on the machine , a typical scenario in development environments.

Unix Shell – Easier Navigation

Found this very useful tip which could make working with Unix shell a very pleasant experience.

Add the following to the .profile file in your home directory:

set -o emacs
alias __A=`echo “20″` # up arrow = ^p = back a command
alias __B=`echo “16″` # down arrow = ^n = down a command
alias __C=`echo “06″` # right arrow = ^f = forward a character
alias __D=`echo “02″` # left arrow = ^b = back a character
alias __H=`echo “01″` # home = ^a = start of line
alias __P=”^P”

And voila!, you can use up/down arrows to navigate through the command history, left/right to move back and fro tthrough the command line, backspace to do what it is supposed to do and so on very similar to what you get on a windows command line.

Works with ksh. Not tested with others.

Sending mail via Telnet

If you have connectivity to a valid SMTP relay server, then you can send a mail via a telnet session:

See below a sample telnet session started with a telnet <smtp server host> <smtp server port>

Commands in red are entered by the user

220 ESMTP Service (Lotus Domino Release 7.0.3) ready
at Thu, 27 May 2010 12:35:25 +1000
helo atheek
250 Hello atheek ([]), pleased to meet
mail from:
250… Sender OK
rcpt to:
250… Recipient OK
354 Please start mail input.
subject: SMTP Demo for atheek’s blog
This is a test message for blog
250 Mail queued for delivery.
221 Closing connection. Good bye.

This blog shows how to use telnet to receive mails from an imap server.

This is useful when you want to troubleshoot issues in email integrations in OSB or SOA Suite.

Posted in General | Tagged , , , , | Leave a comment

Weblogic Filtering Classloaders

At one of my previous customer, we had an ALSB 2.5 installation which uses XMLBeans 2.2 internally for processing XML. There was a requirement to validate inbound XML messages against a 3rd party schema. The schema had some constructs which was recognized only from XMLBeans 2.4. XMLBeans 2.2 classes are there in WLS_HOME/lib folder and hence available in the System CLASSPATH. When we use the Validate action in OSB it always loaded the XMLBeans 2.2 classes from the CLASSPATH and the validate action always failed due to the non support for the new construct.

A solution was proposed to use a custom MDB to do the validation as a pre-requisite stage before passing the XML to ALSB. We followed the best practice of removing Validate action from production build as it is CPU intensive. All validation issues should be flushed out during testing and hence wouldn’t require to do the CPU intensive schema validation at runtime. So this tactical solution was accepted for testing.

We deployed the MDB with the XMLBeans 2.4 classes in the APP-INF/lib folder, but still we could see that 2.2 classes are used for validation.

The reason for this is that Weblogic Classloaders work in a delegation manner where in a query is made to the parent classloaders to search for a class when it is to be loaded. Due to this nature, even though if we put the XMLBeans 2.4 jar within the custom validator application EAR, the actual class that got loaded was the XMLBeans 2.2 one by the System Class loader.


Use Filtering ClassLoaders. Using this feature, we can control the delegation nature of Weblogic Classloaders. We build a MDB which does the XML schema validation in its onMessage() method. The XMLBeans 2.4 jars were put in the APP-INF/lib folder of the EAR. Then added the following construct to the weblogic-application.xml


This instructs the application classloader not to delegate to its parent Classloaders for Classes belonging to the package org.apache.xmlbeans and instead load the classes available in the application package.

Posted in OSB, Weblogic | Tagged , | Leave a comment

Adding namespace to a no namespace XML using XQuery

I recently worked with a customer where their XML standards state that all XML instance documents should be namespace qualified. I was converting a flat file to XML using MFL Transform which doesn’t set a namespace for the transformed XML. The below Xquery can be used to add a namespace to all element nodes in a no namespace XML instance document like the mfl transformed xml.

xquery version "1.0" encoding "Cp1252";
(:: pragma parameter="$noNamespaceXML" type="xs:anyType" ::)
(:: pragma parameter="$namespaceURI" type="xs:string" ::)
(:: pragma type="xs:anyType" ::)
declare namespace xf = "<a href=""></a>";
declare function xf:addNamespaceToXML($noNamespaceXML as element(*),$namespaceURI as xs:string) as element(*)
element {fn:expanded-QName($namespaceURI,fn:local-name($noNamespaceXML))}
for $node in $noNamespaceXML/node()
if (exists($node/node())) then xf:addNamespaceToXML($node,$namespaceURI)
else if ($node instance of element()) then element {fn:expanded-QName($namespaceURI,fn:local-name($node))}{$node/@*}
else $node }

declare variable $noNamespaceXML as element(*) external;
declare variable $namespaceURI as xs:string external ; 
xf:addNamespaceToXML($noNamespaceXML, $namespaceURI)

The above code recursively access all nodes in the xml instance, checks if the node is an element node and qualifies the element node with the passed namespaceURI. Other type of nodes ( text, attributes etc) are not namespace qualified.

<b attr="attribute">text</b>



<ns:a xmlns:ns="">
<ns:b attr="attribute">text</ns:b>

I’ve learnt two points when doing this.

First, OSB doesn’t support fn:QName (function belonging to Xpath domain) which allows namespaceURI and localname as the parameters to create a new namespace qualified element. OSB supports xs:QName (function belonging to xsd domain) which doesn’t serve the same functionality. Instead we need to use fn:expanded-QName() to create elements dynamically.

Second, attribute nodes are not child element of element nodes.

<ns:b attr="attribute">text</ns:b>

If you apply node() function on the element node it returns only the text node “text” and not the attribute node “attr=attribute”. This W3C School link gives the relationship between different nodes and is a useful reference.

Posted in OSB, XQuery | Tagged , , | 3 Comments

Granting OSB Test Console access to Integration Monitors

In situations where you require non developers/administrators to access to OSB sbconsole, the approach followed is to assign these users to the Integration Monitors weblogic role. This grants them a read-only access and can just see the configurations in sbconsole without editing it. We had a requirement to grant our testers access to sbconsole to do some system testing of the middleware components using OSB test framework. We didn’t want to grant admin rights to these testers and hence thought of assigning their user id’s to Integration Monitor role. But by default , OSB doesn’t allow Integration Monitors to access test console. This can be fixed by the below approach.

Weblogic security offers  a pluggable framework whereby you can plug different providers for doing different type of security needs. One type is Authorization providers which implements access control policies which specifies what secured resources can be accessed by users, groups and roles. Weblogic comes with a default XACML Authorization provider which uses the embedded ldap as the store for these access control policies. By default when you create a OSB weblogic domain, the newly created embedded ldap has 2 policies which restrict access to test console to only Integration Admin and Integration Deployer roles.  We can modify these policies using WLST to add Integration Monitors to the allowed list in these 2 policies. Here are the steps to do this:

First create 2 files called Policy.xml and Policy1.xml.


<Policy PolicyId="urn:bea:xacml:2.0:entitlement:resource:type@E@Fwlsb-console@G@M@Opath@E@VTestConsole@W@M@Oaction@ETest" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<Description>Rol(IntegrationAdmin) | Rol(IntegrationDeployer) | Rol(IntegrationMonitor) </Description>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="">type=&lt;wlsb-console&gt;, path={TestConsole}, action=Test</AttributeValue>
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="" MustBePresent="true"/>
<Rule RuleId="primary-rule" Effect="Permit">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:or">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
<AttributeValue DataType="">IntegrationAdmin</AttributeValue>
<SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=""/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
<AttributeValue DataType="">IntegrationDeployer</AttributeValue>
<SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=""/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
                        <AttributeValue DataType="">IntegrationMonitor</AttributeValue>
                        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=""/>
<Rule RuleId="deny-rule" Effect="Deny"/>


<Policy PolicyId="urn:bea:xacml:2.0:entitlement:resource:type@E@Fejb@G@M@Oapplication@EALSB@OTest@OFramework@M@Omodule@EsbTestFwkEjb.jar@M@Oejb@ETestService" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="">type=&lt;ejb&gt;, application=ALSB Test Framework, module=sbTestFwkEjb.jar, ejb=TestService</AttributeValue>
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="" MustBePresent="true"/>
<Rule RuleId="primary-rule" Effect="Permit">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="">IntegrationDeployer</AttributeValue>
<AttributeValue DataType="">IntegrationAdmin</AttributeValue>
<AttributeValue DataType="">IntegrationMonitor</AttributeValue>
<SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=""/>
<Rule RuleId="deny-rule" Effect="Deny"/>

Copy above 2 files to domain home and then start command prompt to run wlst from domain-home

java weblogic.WLST

#connect to admin server of domain -  


cd SecurityConfiguration/&lt;domain_name&gt;/DefaultRealm/myrealm/Authorizers/XACMLAuthorizer






 To confirm that the policies have been updated, go to Admin Console ->Security Realms –  myrealm -> Providers ->XACMLAuthorizer ->Migration -> Export tab and click save.  This will create a XACMLAuthorizer.dat file in domain home ( by default, can change this to other locations). This is a text file which can be opened in any text editor and checked to see whether the polcies been updated to include Integration Monitor.

Posted in OSB, Security | Tagged , , | 15 Comments


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..

Posted in OSB, SAML, Security | Tagged , , , | 15 Comments

Transaction handling within OSB

This gallery contains 7 photos.

I have seen many OSB newbies getting confused about the transaction handling capabilities in  OSB. This is because transaction enlisting and demarcations are implicit in OSB. This means OSB developer have no explicit actions to start/commit/rollback transactions. However it is … Continue reading

Gallery | Tagged , | 26 Comments