Restrict User Access To A Specific BPEL Domain With JAZN Security Provider

BPEL PM allows you to have a fine grained user access at domain level. That means that if you want to restrict a user to a domain (or set of domains) then you should be able to perform this task by following these simple steps.

I am assuming that we have a domain called “development” and we want to have users (e.g. “devuser”) with only “devrole” privilege  to have access to this domain.

To achieve this we need to perform two task, first create user, role at application server and then update security realm using enterprise manager console.

To simplify this, i have scripted first half of the task. It basically creates role “devrole”, assigned domain permissions to “devrole”, create user “devuser” and grant role “devrole” to this user.

set OH=C:\oracle\ora10g\soasuite
set JH=%OH%/jdk
set ADMIN_USER=oc4jadmin
set ADMIN_PWD=oc4jadmin
set ROLE_NAME=devrole
set USER_NAME=devuser
set USER_PWD=welcome1
set DOMAIN_NAME=development

%JH%/bin/java -Xbootclasspath/a:%OH%/bpel/lib/orabpel-boot.jar -jar %OH%/j2ee/home/jazn.jar -user %ADMIN_USER% -password %ADMIN_PWD% -addrole jazn.com %ROLE_NAME%
%JH%/bin/java -Xbootclasspath/a:%OH%/bpel/lib/orabpel-boot.jar -jar %OH%/j2ee/home/jazn.jar -user %ADMIN_USER% -password %ADMIN_PWD% -grantperm jazn.com -role %ROLE_NAME% com.collaxa.security.DomainPermission %DOMAIN_NAME% all
%JH%/bin/java -Xbootclasspath/a:%OH%/bpel/lib/orabpel-boot.jar -jar %OH%/j2ee/home/jazn.jar -user %ADMIN_USER% -password %ADMIN_PWD% -listperms jazn.com -role %ROLE_NAME%
%JH%/bin/java -Xbootclasspath/a:%OH%/bpel/lib/orabpel-boot.jar -jar %OH%/j2ee/home/jazn.jar -user %ADMIN_USER% -password %ADMIN_PWD% -adduser jazn.com %USER_NAME% %USER_PWD%
%JH%/bin/java -Xbootclasspath/a:%OH%/bpel/lib/orabpel-boot.jar -jar %OH%/j2ee/home/jazn.jar -user %ADMIN_USER% -password %ADMIN_PWD% -grantrole %ROLE_NAME% jazn.com %USER_NAME%

Second half task is little bit manual, i would try to script it but for the time being lets do it from EM console.

• Logon to the application server control console, and from the cluster topology, expand the BPEL container. Scroll down and click on orabpel.

• Navigate to Administration -> Security Provider -> Realms

• Click on the number under Roles. Click on Create and add the name you’ve given your new role (e.g. devrole) and check “Grant RMI Login Permission”. Click Apply.

• Go back to the Security Provider page, and click on the number under Users.
• Click create and enter the name of your user and the password In our example, the user name would be “devuser” and the password “welcome1”.
• Assign this user the new role “devrole” and Click OK.

• Now, open the system-jazn-data.xml file in directory ORACLE_HOME/j2ee/oc4j_soa/config for edit.
• In a section titled <jazn-realm> and under that a section labeled <users>. Scroll down and verify that the user you’ve just created on the application server console is listed there.
• In a section labeled <roles>. Verify that the role you’ve just created is listed there and that your user is listed as a member of this group. (Group and role are synonymous in BPEL.)
• Scroll down further to the section labeled . Look for the permissions granted to your new role; you will see something like

• We will need to add the domain permission here. So, add the following text replacing domain name with our domain name “development”.

<permission>
    <class>com.collaxa.security.DomainPermission</class>
    <name>DOMAIN_NAME</name>
    <actions>all</actions>
</permission>

• So it would look like

• Restart the server
• Try to login as “devuser”. You will see that the console comes up in the domain specified for this user. In the drop down list at the top, the user will be able to see any other domains but will be unable to access them.

Failed to lock the record, another user holds the lock.

Error

JBO-26030: Failed to lock the record, another user holds the lock.
oracle.jbo.AlreadyLockedException: JBO-26030: Failed to lock the record, another user holds the lock.

Cause

Two possible causes are:

1. transaction-config timeout is set too low
2. connection caching is enabled

Solution

• Increase the transaction timeout in server.xml to a large number

<transaction-config timeout="120000" />

• Set connectionCachingEnabled  property in /j2ee/OC4J_BPEL/config/data-source.xml to false

<property name="connectionCachingEnabled" value="false"/>

How to control Default BPEL revision

By default in BPEL when we deploy new version of BPEL process then the new version becomes default one for that BPEL process. However, there are situations where we want to override this behavior like wanting to keep an working copy as default BPEL version and continue to deploy new  versions with modification.

To achieve desired objective use the property ‘processDeployAsDefault’ in the domain configuration, which  controls which revision will be the default revision.  If set to "true" the  most recently-deployed version of a process is always the default version. If  set to "false" This means that the most recently deployed version of a  process prior to setting this property to false remains the default version.

Please remember this is a”DOMAIN” level configuration so you have to do this exercise for every BPEL domain in question. All you have to do is to modify domain.xml file which is located at <ORACLE_HOME>\bpel\domains\<DOMAIN_NAME>\config\domain.xml and add below mentioned text anywhere within “bpel-domain-descriptor” element.

<property id="processDeployAsDefault">
<name>Process Version Logic </name>
<value>false</value>
<comment><![CDATA[
         If set to "true" This means that the most recently-deployed version
  of a process is always the default version
         If set to "false" This means that the most recently deployed version
  of a process prior to setting this property to false remains the default
  version
  <p/>
         The default value "true".
         <p/>
         ]]>
</comment>
</property>

Creating copy of JDeveloper BPEL Project

Out of the box, JDeveloper provides couple of templates (Synch and Asynch) for developing BPEL process. However, in real world scenarios, especially within matured SOA environments, you will need to have basic standards like fault handling, notification features built in. In such a case you have a option to use “custom template” option of JDeveloper where you build a BPEL project based upon standards and then mark this project as template. Once you do so JDeveloper will give you that project as an option while selecting template for BPEL project. However this option is little bit flaky. Many times I experienced that new project doesn’t have all the artifacts. So I came up with a small ANT task which serves the purpose. You simply paste this snippet inside your build.xml which JDeveloper creates for your out of box.

<target name="copyProject">
        <property name="sourceDir" value="${basedir}"/>
        <property name="sourceProject" value="${BPELSuitcase.BPELProcess(id)}"/>
        <echo> Step 1: Set target directory and project name</echo>
            <input message="Please enter target directory:" addproperty="targetDir"/>
            <input message="Please enter project names:" addproperty="projectName"/>
            <property name="sourceWSDLNamespace" value="http://otn.oracle.com/samplenawsdlmespace"/>
            <property name="sourceSchemaNamespace" value="http://otn.oracle.com/sampleschemanamespace"/>

            <input message="Please enter target WSDL namespace:" addproperty="targetWSDLNamespace"/>
            <input message="Please enter target Schema namespace:" addproperty="targetSchemaNamespace"/>

        <property name="projectDir" value="${targetDir}/${projectName}"/>

        <echo> Step 2: Copy files from template to New Project </echo>
            <copy todir="${projectDir}" verbose="true" includeemptydirs="false"
                overwrite="false">
                <fileset dir="${sourceDir}">
                    <exclude name="**/output/**"/>
                    <exclude name="**/*.bak"/>
                </fileset>
            </copy>

        <echo> Step 3: Renaming Files </echo>
            <move file="${projectDir}/${sourceProject}.jpr"
                tofile="${projectDir}/${projectName}.jpr" verbose="true"/>
            <move file="${projectDir}/bpel/${sourceProject}.wsdl"
                tofile="${projectDir}/bpel/${projectName}.wsdl" verbose="true"/>
            <move file="${projectDir}/bpel/${sourceProject}.bpel"
                tofile="${projectDir}/bpel/${projectName}.bpel" verbose="true"/>
            <move file="${projectDir}/bpel/${sourceProject}.xsd"
                tofile="${projectDir}/bpel/${projectName}.xsd" verbose="true"/>
            <replace dir="${projectDir}" token="${sourceProject}" value="${projectName}"
                   summary="true"/>

        <echo> Step 4: Replacing Namespaces </echo>
            <replace dir="${projectDir}" token="${sourceWSDLNamespace}" value="${targetWSDLNamespace}"
                   summary="true"/>
            <replace dir="${projectDir}" token="${sourceSchemaNamespace}" value="${targetSchemaNamespace}"
                   summary="true"/>
     </target>

It simply accepts 4 parameters

1. Target Directory – It’s the directory where your project will be places e.g. c:\projects
2. Project Name – Name of your BPEL project, also a folder will be created under your target directory folder you mentioned above e.g. c:\projects\sampleProject1
3. Target WSDL Namespace – This will be target namespace of WSDL in new project.
4. Target Schema Namespace – This will be target namespace of schema in new project.

Apart from that you have two more variables which you need to set i.e.

1. Source WSDL Namespace – WSDL target namespace of your source project.
2. Source Schema Namespace – Schema target namespace of your source project.

Once you complete this, you can simply run that target and you are good to go.

Top Down web service in JDeveloper BPEL Projects

Many a times its not possible to use the WSDL created by JDeveloper in BPEL project because of various reason like

• SOA Governance standards
• WSDL shipped by vendor or partner or third party application
• etc.

For such reasons we have to develop our BPEL project in a slightly different way. Below I am presenting step by step guide to accomplish the above mentioned task. Hope this helps.

Select on Workspace > New Project > BPEL Process Project, click OK

Select Empty BPEL Process from “Template” top-down menu, Click Finish.

Please note that here I am selecting Empty BPEL process for the sake of simplicity, however you can follow pretty much the same steps in other templates (including custom templates). Idea is to create a partner like with custom WSDL and attach it with receive (or pick) activity.

You should now see an Empty BPEL Process with main scope and no activities

 

Now move your mouse to “Services” swim lane and right click, Select “Create Partner Link”

For the test purpose, I am picking customerPartyMaster.wsdl shipped with OAGIS 9.2 model. I hosted that WSDL on web server to avoid hassles of maintaining references.

It will prompt you to create “Partner Link Types” section in WSDL, please select “Yes”.

This will create a Ref WSDL which imports WSDL you specified and adds “Partner Link Type” section to it.

Now select the Partner Link Type, Partner Role and My Role.

Now drag “Receive” activity in your project. Point receive to “client”, this way your WSDL becomes the WSDL of your BPEL process. Select the operation you want to use for this BPEL project. If you want to make this BPEL multi-operation BPEL i.e. BPEL exposing more than one operatin, please use “Pick” activity to do so. Rest of the steps remains the same.Click on the “Wizard” icon to create InputVariable. It should automatically pick up data type based on the selected operation.

Click OK (on both create variable and Receive activity).

Now drag “Reply” activity to your project and point it to “client” partner link. Select the operation and create response variable for that.

Now putting sample assign activity which maps one field of input variable to one in output variable

Click OK, your assign should look like this.

Click OK and your project should look like this

 

This completes your BPEL process with custom WSDL. Now you should be able to deploy it and test it on BPEL server.

To test this project, would recommend using SOAP UI for testing. Testing page shipped with application is not always reliable. SOAP UI is still gold standard for me.

Check endpoint property for the port and operation which we used for the project

Create new request for the operation which we used in BPEL and pick the right endpoint location from the dropdown.

Prepare the request and send it to BPEL Server

 

Response from the BPEL process.

This completes our exercise.