How to see the user in the subject of a running BPEL Process?

To supplement my previous blog post, you might be wondering how to see the user in the subject of a running bpel process? Well you can always use external software like TCP Monitor, fiddler, etc to analyze the http traffic and extract the user in the subject. There is another simple way to do this during development time using bpelx:exec activity. 

As you might be knowing that there is a Java Embedding activity which can be used to execute java code fragments in a bpel process. There are a number of other useful things you can do with bpelx:exec activity. One of them is using it to print the principle in the subject in the soa log. Just drag and drop the Java Embedding activity into the bpel process and copy paste the below code into it and you are done.

java.security.AccessControlContext acc = java.security.AccessController.getContext();  
javax.security.auth.Subject subject = javax.security.auth.Subject.getSubject(acc);  
  
System.out.println("*******************************************");  
System.out.println("#####USER NAME IN THE SUBJECT : " + subject.toString());  
System.out.println("*******************************************");

This will result in addition of the bpelx:exec into your bpel process code as shown below:

<bpelx:exec name="Java_Embedding1" version="1.5" language="java">
      <![CDATA[/*Write your java code below e.g. 
    System.out.println("Hello, World");
*/
java.security.AccessControlContext acc = java.security.AccessController.getContext();  
javax.security.auth.Subject subject = javax.security.auth.Subject.getSubject(acc);  
  
System.out.println("*******************************************");  
System.out.println("#####USER NAME IN THE SUBJECT : " + subject.toString());  
System.out.println("*******************************************");]]>
    </bpelx:exec>

As you might have noticed we need to use the complete package name along with the class inside the bpelx:exec as there is no provision to import libraries here.

--Gupt

Identity Switching in BPEL

Imagine a simple bpel process A that has an invoke activity which invokes an external webservice. Now, we wrap this bpel process with OWSM security policies. With OWSM in place, if the BPEL process is invoked as say, UserA, the external webservice also gets called under the same user's security context.

Many a time, we get a usecase where we might need to invoke the external webservice as a different user. With the authorization policies defined at the external web-service end, this might seem really complex. There are multiple alternatives to do this. In this blog, I discuss one of them where the invoke activity alone is switched to contain the second user's identity.

Step 1:

One assumption is that the service end of the web service is secured using  oracle/wss11_saml_token_with_message_protection_service_policy. If this is not the case, create a composite containing a Mediator that invokes the external service. Secure the endpoint of the composite using the oracle/wss11_saml_token_with_message_protection_service_policy. 

Step 2:

Starting from FMW PS2, there is a new owsm policy that has been introduced to handle such use cases. The policy is ' oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy'. You need to make sure that the end point is secured using this policy


Step 3:
All we need to do is to set the value of the property javax.xml.ws.security.auth.username in the normalized message to the required user id before it makes a call to the webserice.


We can find the above property in the 'properties' tab of the invoke activity.

Once you select the required value the invoke xml fragment will look something like below.

<invoke name="xxxx"
           inputVariable="xxx"
           portType="xxx"
           partnerLink="xxxx"
           operation="execute">
           <bpelx:inputProperty name="javax.xml.ws.security.auth.username"
                                        variable="variable name"
                                        part="variable part"
                                        query="xpath to the variable containing the user id"/>
 </invoke>

This is the only change that need to be done at the code level.


Step 4:

We need to add a grant in the system-jazn-data.xml to the wsm-agent-core.jar and specify the Composite App for which OWSM will accept the externally supplied identity. The grant looks something like below. (you can add this via EM as well if you are not comfortable editing the file manually.)


 <grantee>
    <codesource>
        <url>file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar</url>
    </codesource>
</grantee>
<permissions>
    <permission>
        <class>oracle.wsm.security.WSIdentityPermission</class>
        <name>resource=<Your Composite Name></name>
        <actions>assert</actions>
    </permission>
<permissions>


Thats it. Restart the servers after making the changing to the system-jazn-data.xml file so as to reflect the changes and you are all set!


--Gupt

Back!!

So here I am back to blogging.. Not that I used to blog quite frequently earlier. But I once had a blog, 5 years back. Instead of whiling away time on weekends, it just occurred to me - ' How about writing?' and here I come. There are lot of thoughts and views I have on the things happening around me which I want to put forth. One set of them is things related to work. Whenever I start doing something new, I google for it. I come across lot of blogs and articles that helped me greatly in finishing my tasks. I just thought, why not put my own set of leanings and explorations in the areas of Oracle SOA 11g over web so that these might come as use to other developers as well? So, this blog id dedicated to my work area - Oracle SOA 11g, Fusion Middleware and other technical stuff. I do plan to start another blog where I plan to write about thoughts in the other half of my brain. :)

--Gupt