FAQ - OWSM 10.1.3 : Is SOAP 1.2 supported?

OWSM 10.1.3.1 gateway and agents support SOAP 1.1 only at this time. SOAP 1.2 support is being earmarked to be made available as part of 10.1.3.4 patchset.

News: Oracle offers to buy BEA for $6.7 billion

This is a big news today.
Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.
See http://www.oracle.com/bea/index.html for full details.

How To - 10.1.3 OWSM: Access web service operation name in a custom step

When writing an OWSM policy custom step, you may need to determine what the operation name is for the incoming request. You can use the following API to retrieve the operation name.

MessageContext msgCtxt = (MessageContext) ctx;
String operation = msgCtxt.getRequest().getMethodName();

This will return localpart of the first child element of SOAP Body.
The above API will return Echo as the operation name in the example below.

<env:Envelope ...>
  <env:Body ...>
    <ns1:Echo xmlns:ns1="http://echoapp">
    ...
    </ns1:Echo>
  </env:Body>
</env:Envelope>

How To - 10.1.3 OWSM: Console authentication against different user repository and delegated administration

OWSM Console(also known as Control) authentication uses a very flexible pluggable framework. Admin user authentication can be done through either

• Native OWSM authentication - This provides a pluggable authentication provider that can authenticate users against any datastore (such as LDAP, database, etc). The out-of-box implementation defaults to OWSM database. Delegated administration (such as admins with view only access) of OWSM Console is enabled with this option.
• JSSO (Java Single Sign On) - This provides a pluggable authentication provider for SSO to integrate with SSO solutions (such as OAM, Siteminder) as well as provides a default SSO implementation called JSSO. The default implementation of JSSO uses JAAS loginmodule for authentication which allows you to plug-in authentication against any user/role repository. Delegated administration (such as admins with view only access) of OWSM Console is not available with this option.

What you get with the install?
When you install OWSM, the default option you get for console authentication is based on the type of install. You get,

• JSSO for Basic SOA suite installation
• Native authentication for Advanced SOA suite installation, and standalone OWSM installs.

How to manage user/roles for native authentication?
Native authentication defaults to OWSM database for user/role repository where user/roles are stored in a table. These users/roles can be managed through the wsmadmin tool by running the command
wsmadmin manageUserGroups
The default user is admin that has super user privileges to access all parts of the console. This default user can be changed by following this post.

You can use the same command to add/modify other admin users with different privileges(such as view only access provided to users with service support role ss1-grp). See OWSM documentation for details on how to assign roles.

How to change authentication provider to point to LDAP?
You can change the user/role repository to point to LDAP(incl. AD) instead of database by following the steps listed in OWSM documentation.

How to enable JSSO for authentication?
Follow instructions listed here in OWSM documentation to switch from native authentication to JSSO.

How To - 10.1.3 OWSM: Secure asynchronous BPEL process callback

Asynchronous BPEL process callback can be secured using OWSM in one of the following 2 ways.
1. Using server side gateway only
2. Using server agent and client side gateway

In either of the solution the key thing to do is to change the WS-Addressing ReplyTo header to point to a virtualized endpoint of a gateway.

1. Using server side gateway only


In this deployment, you only have server side gateway protecting BPEL process. Follow these steps to secure the callback.

• Register web service in the gateway (e.g. SID0003001)
• Register callback in the gateway (e.g. SID0003002)
• Add XML transform step in policy pipeline for SID0003001 that transforms ReplyTo WS-Addressing header to SID0003002

2. Using server agent and client side gateway

In this deployment, you don't have any gateway on server side. Instead the BPEL proecess is being protected using OWSM server agent. Follow these steps to secure the callback in this case.

• Register callback in the client gateway (e.g. SID0003002)
• Add XML transform step in request policy pipeline for server agent that transforms ReplyTo WS-Addressing header to SID0003002

Add an "XML Transform" policy step to the request pipeline on server gateway or agent with the following contents. Remember to modify it to suit your component id.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template name="do-replace">
    <xsl:param name="text"/>
    <xsl:param name="replace"/>
    <xsl:param name="by"/>
    <xsl:choose>
      <xsl:when test="contains($text,$replace)">
        <xsl:value-of select="substring-before($text,$replace)"/>
        <xsl:value-of select="$by"/>
        <xsl:value-of select="substring-after($text,$replace)"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$text"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
  <xsl:template match="*">
    <xsl:copy>
    <xsl:copy-of select="@*"/>
    <xsl:apply-templates/>
    </xsl:copy>
  </xsl:template>
  <xsl:template match="text()">
  <xsl:call-template name="do-replace">
  <xsl:with-param name="text" select="."/>
  <xsl:with-param name="replace" select="'8889/orabpel/default/Process1/1.0/Service/ServiceRequester'"/>
  <xsl:with-param name="by" select="'8889/gateway/services/SID0003002?wsdl'"/>
  </xsl:call-template>
   </xsl:template>
</xsl:stylesheet>

How To - 10.1.3 OWSM: Send username/password in HTTP header of outbound message from gateway to the web service

OWSM gateway acts as a proxy in accepting requests, perform some processing on it, and then forwarding the request to the actual endpoint.
If the actual endpoint requires credential to be sent in HTTP header (Authorization header also known as HTTP Basic header), then gateway can be configured to send such credentials.

Edit details of the registered service through OWSM Control (UI) setting "Forward Credentials" option to true.

Where do the credentials to be sent come from?
Credentials that need to be sent by the gateway to the actual endpoint should be known to the gateway through either
a. "Extract Credentials" policy step (or)
b. Setting them in a custom policy step using the following API
import com.cfluent.pipelineengine.container.MessageContext;
MessageContext ctx = (MessageContext) messageContext;
ctx.setUnverifiedUserid(username);
ctx.setUnverifiedPassword(password);

How To - 10.1.3 OWSM: Extracting user credentials in gateway

OWSM Gateway supports multiple protocols including HTTP, JMS, MQ, Form and custom for both inbound and outbound messages.
Client user credentials can be sent as part of transport headers or SOAP message.
Following describes a short list of how credentials can be extracted. For complete list, refer to OWSM documentation.

• HTTP transport - Username/password can be passed in the Authorization header (this mechanism is also commonly known as HTTP Basic). "Extract Credentials" step in policy pipeline can be used to read this value.
• JMS transport - Username can be passed in JMS request message property JMS_TIBCO_USER by the client. This value can be accessed inside an OWSM custom policy step using the following API

  String userName = ctx.getHeader("JMS_TIBCO_USER");

  Additionally, any of the JMS message properties passed with the request message can be retrieved in the custom step by using the API

  String value = ctx.getHeader(propertyName);

• SOAP message - Username/password can be passed as a standard WS-Security Username token or passed in a non-standard fashion as elements of the message (header or body). "Extract Credentials" step in policy pipeline can be used to read the username/password. For other types of credentials such as SAML, OAM token, X.509 "Extract credentials step is not required, and corresponding steps that processes such tokens can be used.

How To - 10.1.3 OWSM: Find location of virtualized service provided by the gateway

OWSM Gateway virtualizes the service endpoint.
1. For SOAP based web services, the virtualized endpoint would be the following http://gateway-host:port/services/SID000300x
or
http://gateway-host:port/services/url-encoded-web-service-name
Here, url-encoded-web-service-name refers to the name used at service registration time that has been url encoded. For example, "Hello World WS" will be represented as "Hello%20World%20WS".

2. For XML based web services, the virtualized endpoint would be the following
http://gateway-host:port/xml/SID000300x
or
http://gateway-host:port/xml/url-encoded-web-service-name