How To - 10.1.3 OWSM: Install a standalone Gateway

You may want to install OWSM Gateway on a different machine (such as one in DMZ) than rest of the OWSM components (such as policymanager, monitor, console). But, OWSM or SOA suite installer doesn't have an option to install only the gateway. You can follow the following procedure to perform such a Gateway only installation.

Step 1: Install standalone OWSM (using Advanced option)

During install, you will be required to enter database details. You can either

• provide existing database details where ORAWSM schema exists. The installer won't modify existing tables, but as a best practice take the database backup before performing this operation. (or)
• create a dummy database just for this installation, and run irca script on it before performing install.

You will need to follow this sequence to get to the current patch level.

1. Install 10.1.3.1 OC4J
2. Install 10.1.3.1 OWSM
3. Apply 10.1.3.3 patchset. Note: The above sequence is required, as you cannot install OWSM on top of 10.1.3.3 OC4J.

Step 2: Undeploy policymanager, coreman, and ccore applications from the new installation

Step 3: Reconfigure the gateway to communicate with existing policy manager and monitor

1. Login to OWSM console, and add the gateway component.
2. Once the gateway component is added, click the Edit icon and modify cfluent.monitor.rmi.host to point to the existing monitor application running elsewhere.
3. Open OC4J_HOME/owsm/config/gateway/gateway-config-installer.properties, and modify gateway.policymanagerURL in addition to other properties required for configuring the gateway
4. Re deploy the gateway using wsmadmin tool (wsmadmin deploy gateway)

Step 4: Verify database details for SOAP message logging

SOAP messages are logged to OWSM database by default when "Log" policy step is added to the request/respsone policy pipeline. If you don't plan to use SOAP message logging, then disable this functionality.

1. Login to OWSM console, and click the Edit icon for the gateway component.
2. To disable message logging, change cfluent.messagelog.enabled property to false.
3. To reconfigure the database used for message logging, modify the properties clfuent.messagelog.db.*

OWSM Critical Patch Update - Dec 2007

A critical patch for OWSM has been released that may be required if you have applied the 10.1.3.3 Patch Set on the 10.1.3.1 product install. Get full details about the one-off patch here.

How To - 10.1.3 OWSM: Setup agent on OC4J communicating with remote policy manager and monitor

If you have a web service or client running on OC4J, and you want to protect it using OWSM agent communicating with remote policy manager and monitor, then follow the following steps.

1. Install 10.1.3.1 OC4J
2. Install 10.1.3.1 OWSM
3. Apply 10.1.3.3 patchset. Note: The above sequence is required, as you cannot install OWSM on top of 10.1.3.3 OC4J.
4. Uninstall policymanager, coreman, and ccore applications from OC4J
5. Login to OWSM console, and add the agent component.
6. Once agent component is added, click the Edit icon and modify cfluent.monitor.rmi.host to point to the existing monitor application running elsewhere.
7. Open OC4J_HOME/owsm/bin/agent.properties, and modify agent.policymanagerURL in addition to other properties required for configuring agent
8. Deploy the agent using wsmadmin tool

Agent will be ready to get policies from the right policy manager, and send metrics to the right monitor.

Best Practice - 10.1.3 OWSM: Configuration management for agents

When you deploy agents, you configure OH/owsm/bin/agent.properties. Now, if you have multiple agents you can quickly overwrite the configuration used for a previous agent deployment.
As a best practice, after you deploy an agent, copy the agent.properties file to __agent.properties (such as SID0003002_HelloWorld_agent.properties), and put it under source code control.
At a later point, if you need to redeploy the application you can quickly pull out the corresponding agent.properties file from source code control system and deploy the agent for the redeployed application.
Additionally, also put OH/owsm/config/serveragent or OH/owsm/config/clientagent directory under source code control. These directories contain configuration items for the agent runtime that can be customized, and you may want to version control it.

How To - 10.1.3 OWSM: Access the processed SAML token in a custom step

In some situations you may want to access the SAML token processed by the "Verify SAML token" policy step in a subsequent custom step.
The API to access it is

ArrayList samlAssertions = msgctx.getProperty("SAML_ASSERTIONS");
if(samlAssertions != null) 
  String samlAssertion = samlAssertions.get(0);

News: Apply OWSM 10.1.3.3 patchset

OWSM 10.1.3.3 patchset was released couple of months back. If you haven't patched your 10.1.3.1 installation yet, then I would strongly recommended you to do it.
Apart from many bug fixes, some enhacements also went into the patchset.

• Gateway can register services whose wsdl imported another wsdl or schema (xsd). This is very common in Oracle BPEL, and a workaround was required to be applied in 10.1.3.1 to put the imported wsdl or xsd in OH/j2ee/home/applications/gateway/gateway/services folder. This workaround is no longer required if the patchset is applied.
• Purge old policy versions using WSM console.
• Purge old message logs using WSM console
• Oracle WSM Server Agents for AXIS 1.4 on OC4J are supported.
• SOAP with attachments (SwA) messages can be processed by Oracle WSM Gateways and Agents, where the messages are neither signed nor encrypted.
• Custom steps in the Oracle WSM Gateway can add or modify outgoing HTTP headers.

The documentation guides also underwent updates

• SSL information is more complete
• Extensibility guide has more details with examples

How To - 10.1.3 OWSM: Propagate identity by inserting SAML token using OWSM client agent or gateway

When an application or web service calls another web service, you may want to propagate the identity of the user that first logged into the application or service.
OWSM client agent or gateway can be used to accomplish it.
The basic design is to read the user identity from the java Subject and then convert it into a SAML token.

Step 1: Read java Subject in your application, and create a custom SOAP header.
Subject subject = Subject.getSubject(AccessController.getContext());
Now, using the subject value to lookup username and roles, create the following custom SOAP header. Propagating roles is optional.

<env:Envelope ...>
  <env:Header>
    <custom:userInfo xmlns:custom="http://custom/ns">
      <username>JSmith</username>
      <roles>role1,role2</roles>
    </custom:userInfo>
  </env:Header>
  <env:Body>
  ...
  </env:Body>
</env:Envelope>

Step 2: Convert custom header to SAML token in OWSM client agent or client gateway
Add the following steps in the request pipeline of a client agent or client side gateway.

a. Custom step - Create a custom step that will read the custom SOAP header from the request and set the values in the message context that would be picked up the "Insert SAML step". Refer to OWSM extensibility guide for details on how to develop custom steps.

// read the username from custom header, and set it using API below
// this value will be used to represent SAML Subject
ctx.setUnverifiedUserid(username);

// if roles needs to passed
SOAPElement customHeader = ...
HashMap userMap = new HashMap();
ArrayList roles = new ArrayList();
//add the roles read from custom header. roles.add(...);
userMap.put("roles", roles);
msgCtxt.setProperty(MessageContext.USER_ATTRIBUTES, userMap);

// delete the custom SOAP header from the request message
customHeader.detachNode();

b. Insert SAML step - this will generate the SAML sender-vouches token, and add it to the SOAP Security header.

How To - 10.1.3 OWSM: Increase the 50 web services limit for the Gateway

OWSM Gateway by default comes with a limit of 50 web services that can be registered with it. This is a soft limit, and can be changed as follows.

Modify /owsm/config/ccore/ui-config-common.properties
changing this property to whatever limit you want
ui.pm.maxNumberOfPolicies=50

Redeploy the ccore application by going to OC4J_HOME/owsm/bin directory and running the following command
wsmadmin deploy OC4J_ADMIN_PASSWORD ccore

News: Cisco buys Securent for $100 M in cash

Cisco® (NASDAQ: CSCO) today announced an agreement to acquire Securent, Inc., a leading provider of entitlement management software for enterprises. Securent is privately held and based in Mountain View, Calif.
Complete story http://money.cnn.com/news/newsfeeds/articles/marketwire/0322664.htm

This clearly validates the demand in the marketplace for content and context based authorization using standards such as XACML.

Origins of OWSM which was originally developed by Confluent Software can be linked to Sekhar Sarukkai who is CTO and co-founder of Securent.
Incidentally he was also the co-founder of Confluent Software which Oblix had purchased to add web services security to its portfolio of IdM products. Oracle acquired Oblix in 2005, and released this product as Oracle Web Services Manager (OWSM).

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

How To - 10.1.3 OWSM: Access OAM action header values in a custom step

OWSM integrates with Oracle Access Manager(OAM) using "Oracle Access Manager Authenticate Authorize" policy step. As part of authentication/authorization OAM can return action header variables back to OWSM, if return action is configured in OAM authentication scheme. Typical usage is to return a certain user attribute or groups that the user belongs to (using obmygroups as the header variable). See OAM documentation for further details on this functionality.

These action header values can be retrieved in an OWSM custom policy step through the following API

HashMap headers = msgCtxt.getProperty(MessageContext.USER_ATTRIBUTES);

How To - 10.1.3 OWSM: Display monitoring metrics for more than 100 minutes (around 2 hrs)

OWSM by default displays monitoring metrics only for the last 100 minutes (close to 2 hrs). The setting can be changed by folowing the below procedure.

Open the configuration file OC4J_HOME/owsm/config/coreman/monitor-config-installer.properties, and modify the following property to the desired value.
monitor.aggregator.measurementStore.windowSize=100

Redeploy the monitor application by going to OC4J_HOME/owsm/bin directory and running the following command
wsmadmin deploy OC4J_ADMIN_PASSWORD coreman

FAQ - OWSM 10.1.3 : Basic install Vs Advanced install

OWSM 10.1.3.1 install has 2 options - Basic and Advanced
Basic install runs on oc4j_extended.zip, while Advanced install runs on production quality OC4J.
Basic install is targeted for usages such as developement, POC, and trainings.
If you have installed the product using Basic install, then you can't migrate it to Advanced install. You have to reinstall the product as Advanced install.

How To - 10.1.3 OWSM: Use PKCS12 certificates for signing, encryption

Oracle Web Services Manager (OWSM) 10.1.3.1 uses certificates to sign/encrypt and decrypt/verify the SOAP messages. The certificate stores supported for certificate lookup are JKS and PKCS12.
OWSM 10.1.3.1 supports PKCS12 only with BouncyCastle as the security provider. Sun security provider is not supported at this time. If Java keytool is used to create PKCS12 certificate store, then follow the instructions in this post to create the PKCS12 store that is compatible with OWSM.

How To - Creating PKCS12 certificate store with BouncyCastle provider

PKCS12 certificate store can be created using various tools such as Java keytool, Microsoft Certificate Authority Service, and OpenSSL.
When Java keytool is used to create PKCS12 store, it creates using the Sun provider.

The following instructions allow you to create a PKCS12 store with BouncyCastle provider.

1. Modify java.security file under JRE_HOME/lib/security directory to include BouncyCastle as the security provider.
   Add the following entry under the section "List of providers and their preference orders", security.provider.x=org.bouncycastle.jce.provider.BouncyCastleProvider.
   Make sure the entry is added above security.provider.x+1=com.sun.net.ssl.internal.ssl.Provider
   (Here x is the index of the sequence of service providers.)


2. Put BouncyCastle jar under JRE_HOME/lib/ext directory.
   Tip: If using OWSM 10.1.3.1, instead of downloading you can copy it from ORACLE_HOME/owsm/lib/extlib/bcprov-jdk14-119.jar


3. Run keytool from JRE_HOME/bin directory.
   keytool -genkey -v -alias aprivatekey -keyalg RSA -keystore
   mykeystore.p12 -storepass changeit -storetype pkcs12 -provider org.bouncycastle.jce.provider.BouncyCastleProvider

Contributed by Rohit Soni

OWSM wins SOAWorld Reader's choice award for best security solution

Oracle Web Services Manager(OWSM) was voted one of the best security solutions by SYS-CON Media (http://www.sys-con.com/), the world's leading i-technology media and events company in it's 2007 SOAWorld Readers' Choice Awards. There are multiple Oracle products winning in other categories as well

• Best Security Solution - Oracle Web Services Manager


• Best App Server - Oracle Fusion Middlware


• Best BPM Engine - Oracle BPEL Process Manager


• Best GUI for Web Services Product - Oracle JDeveloper


• Best IDE - Oracle JDeveloper


• Best Integrated Services Environment - Oracle JDeveloper


• Best Legacy Adapter - Oracle Integration Adapters


• Best Portal Platform - Oracle Portal


• Best SOA/Web Services Book - BPEL Cookbook: Best Practices for SOA-Based Integration and Composite Applications Development, Packt Publishing


• Best SOA/Web Services Platform - Oracle Fusion Middleware


• Best Tool/Platform - Oracle Developer


• Best Web Services Testing Tool - Oracle Developer


• Best XML Database - Oracle XML DB


• Best XML Parser - Oracle XDK


• Best XSLT Processor - Oracle XDK

The awards recognize the best tools, solutions, and education offerings in fully 20 categories. Winners were selected through reader-submitted nominations, followed by online voting at SOAWorld (http://soa.sys-con.com/), the world’s leading source of SOA news and information.

WS-SecurityPolicy 1.2 approved

WS-SecurityPolicy 1.2 specification has been approved as an OASIS Standard.

WS-ReliableMessaging v1.1 approved

WS-ReliableMessaging v1.1 specification has been approved as an OASIS Standard. The specification contains

• Web Services ReliableMessaging 1.1
• Web Services ReliableMessaging Policy 1.1
• Web Services MakeConnection 1.0

Oracle Fusion Middleware 11g Technology Previews(JDeveloper/ADF and OC4J)

Visit OTN's Java Developer Center to download Technology Previews of Oracle JDeveloper and ADF 11g and the Java EE 5.0-compliant Oracle Containers for Java 11g. These previews are designed to make it easier to develop and deploy Java EE 5, Web 2.0, and AJAX-style Rich Internet Applications.

Try the new features in web services security such as support for WS-Policy 1.1 and WS-SecurityPolicy 1.1 specifications, and how they help service providers publish their security requirements in service WSDL automatically through the WS-PolicyAttachment 1.1 specification. Both WS-Security 1.0 and WS-Security 1.1 are supported in this release.

How To - OWSM 10.1.3 : Implement last mile security with gateway

OWSM gateway can be used to protect web services. Since, gateway runs as a separate process, the channel between gateway and the web service can remain unsecured (also known as last mile security). Also, direct access to the web service (bypassing the gateway) should be disallowed.

Any of the following options can be implemented to secure the channel between the gateway and web service,

1. Network level access control - Restrict the web service machine to communicate with the gateway machine only. This is a quick and dirty solution, but may not be always desirable.


2. Use client certificate auth SSL (also known as 2 way SSL) between gateway and web service - This will ensure that only the gateway app can talk to the web service.


3. Install server agent on the web service - After verifying security for the incoming messages, the gateway would sign the message that it forwards to the web service using it's private key. The server agent would verify the signature, and validate the certificate used for signing. This will ensure that direct access to the web service is not possible.

FAQ - OWSM 10.1.3 : What is the use of cerificate alias in Verify signature step

In OWSM 10.1.3.x, verify signature step verifies the signature using the client certificate present as Binary Security Token (BST) in the SOAP message. It doesn't use the certificate alias from step configuration for signature verification.
The certificate alias from step configuration is used for verifying the chain of the incoming certificate in BST. The alias can point to either of the following.

• root certificate authority (CA) certificate
• intermediate certificate authority (CA) certificate
• "*" - The certificate chain is verified against all the trusted certs in the keystore. Any one of the trusted certs should match. This is particularly useful when you have requests coming from multiple clients that don't share the same intermediate or root CA certificate.

Project Concordia

Worried about too many competing specifications driving the identity management landscape? Not sure which one to pick for your organization? Some of these worries are being put to rest by Project Concordia. It's a global initiative with representatives from the CardSpace, Liberty Alliance, OpenID, openLiberty.org, SAML 2.0 and WS-Federation communities to provide interoperability between these identity standards by creating profiles based on use cases. Eventually, some of these specifications should merge.

The work has already started with the first meeting between Liberty SAML 2.0 and Microsoft representatives to be held during the Burton Catalyst 2007 in San Francisco.

How To - OWSM 10.1.3 : Use LDAP to authenticate admin users into OWSM Control(UI)

By default, OWSM uses user/group information from the users and groups tables in the configured database. In addition, the groups are linked to roles in the group_role_mappings table.

To switch the authentication identity provider from the database(default) to LDAP, follow these steps from the Admin guide.

Now, pick a group in LDAP whose members will be allowed full access to the OWSM Control. Lets say, it is owsm-administrators.

Add a group role mapping for this group in the group_role_mappings table by executing
insert into group_role_mappings values ('owsm-administrators',1,'Y');

Voila! You have successfully switched the authentication store for Control application to LDAP.
Also see this post on OTN.

Highlights from JavaOne2007

Top areas that got due attention during the Java One 2007 conference held at Moscone Center in San Francisco were

1. Rich clients / Web 2.0 - Sun's JavaFx, Adobe's Flex, Open source OpenJfx, Oracle's Silverlight were the most talked about topics. Several sessions covered the rich client technology.
2. Service oriented architecture (SOA) - There was a separate sessions track on it. Many companies showcased mashups with SOA and the Service Component Architecture (SCA) offerings.
3. Mobile device programming - Motorola, Nokia, Sun and others showcased programming for mobile devices.
4. Ruby on Rails - This new programming framework was on everyone's mind with JRuby providing the java implementation.

Oracle was a platinum sponsor, and had a grand presence in the show. You can watch Thomas Kurian's keynote here.

Finally, more than 600 attended the presentation on web services security which I did alongwith Marc Chanliau. This was inspite of it being on the last day of the show. Security is a HOT topic.

How To - OWSM 10.1.3 : Add help page for custom steps

You can add a help page for custom policy step in 10.1.3.1 Oracle Web Services Manager (OWSM) by following these steps:

1. Navigate to the OC4J_HOME/owsm/lib/app/ccore/help/steps directory


2. Create the html help page for the custom page here and name it with the step name replacing any spaces with underscore. For example, if the step name is “My Custom Step” then name the help page as My_Custom_Step.html

You can optionally create help pages in other languages and put them under the respective directories such as es, fr, etc.

1. Start the OC4J server


2. On command prompt, go to OC4J_HOME/owsm/bin directory and run the following command

wsmadmin deploy OC4J_ADMIN_PASSWORD control

This will package the control application again with the newly added help page, and redeploy it into the OC4J container.

Login to the OWSM Control. Help for your custom step should be available now.

FAQ - OWSM 10.1.3 : Types of logging

Oracle Web Services Manager (OWSM) 10.1.3.1 performs 2 types of logging.

1. Message logs - This can be configured in the policy as a policy step. The SOAP message is logged/stored in the database.

2. Diagnostic logs - These logs are written into filesystem at ORACLE_HOME/j2ee/OC4J_Instance/log.
Each of the OWSM application has their own logs - gateway.log, serveragent.log, clientagent.log, policymanager.log, monitor.log, ccore.log.
To get detailed diagnostic logging, the log level can be changed as per this post.

Additionally, customers can implement custom policy step to send message logs to a centralized logging application. Refer to OWSM Extensibility guide for creating custom policy steps.

How To - OWSM 10.1.3 : Change log level

The out-of-box log level is “INFO” for all OWSM applications. For debugging purposes, you may want to bump this log level to get further details on the problem. Following instructions will allow you to achieve this.

OWSM Gateway

1. Make sure that OC4J application server is running.
2. Open OC4J_HOME/owsm/config/gateway/logging.xml and replace all “INFO” with “ALL”.
3. Go to OC4J_HOME/owsm/bin directory, and run the following command
   wsmadmin deploy OC4J_ADMIN_PASSWORD gateway
4. The changed log level for the gateway application is in effect now. Look for the detailed logs in OC4J_HOME/j2ee/OC4J_Instance/log/gateway.log

OWSM Control

1. Make sure that OC4J application server is running.
2. Open OC4J_HOME/owsm/config/ccore/logging.xml and replace all “INFO” with “ALL”.
3. Go to OC4J_HOME/owsm/bin directory, and run the following command
   wsmadmin deploy OC4J_ADMIN_PASSWORD control
4. The changed log level for the gateway application is in effect now. Look for the detailed logs in OC4J_HOME/j2ee/OC4J_Instance/log/ccore.log

OWSM Policy Manager

1. Make sure that OC4J application server is running.
2. Open OC4J_HOME/owsm/config/policymanager/logging.xml and replace all “INFO” with “ALL”.
3. Go to OC4J_HOME/owsm/bin directory, and run the following command
   wsmadmin deploy OC4J_ADMIN_PASSWORD policymanager
4. The changed log level for the gateway application is in effect now. Look for the detailed logs in OC4J_HOME/j2ee/OC4J_Instance/log/policymanager.log

OWSM Monitor

1. Make sure that OC4J application server is running.
2. Open OC4J_HOME/owsm/config/coreman/logging.xml and replace all “INFO” with “ALL”.
3. Go to OC4J_HOME/owsm/bin directory, and run the following command
   wsmadmin deploy OC4J_ADMIN_PASSWORD monitor
4. The changed log level for the gateway application is in effect now. Look for the detailed logs in OC4J_HOME/j2ee/OC4J_Instance/log/coreman.log

OWSM Agents on OC4J

Server Agent or J2EE Client Agent

1. Make sure that OC4J application server is running.
2. Open OC4J_HOME/owsm/config/interceptors/componentId/config/clientagent or serveragent/logging.xml and replace all “INFO” with “ALL”.
3. Restart the application.
4. The changed log level for the serveragent application is in effect now. Look for the detailed logs in OC4J_HOME/j2ee/OC4J_Instance/log/serveragent.log for serveragent (and clientagent.log for client agents).

How To - OWSM 10.1.3 : Change default password of admin user accessing OWSM Control when JSSO is disabled

When JSSO is disabled, Oracle Web Services Manager (OWSM) Control authenticate users at login time with the users present in a database table. To change the default password for the user "admin", follow these steps:
- delete admin user
- add admin user back
- add admin user to the super user group "su1-grp"

1. Go to OC4J_HOME/owsm/bin directory and modify manageUserGroups.properties
user_id=admin
user_name=admin user
user_password=yourNewPassword
user_email=admin@xyz.com

group_id=su1-grp
group_desc=super user group

2. Delete the existing admin user by executing
wsmadmin manageUserGroups deleteUser

4. Add the admin user again by executing
wsmadmin.bat manageUserGroups addUser

5. Add admin user to super user group
wsmadmin.bat manageUserGroups addUserGroup

The admin user password is changed.

Presenting Technical Session TS-8131 on Web Services Security in JavaOne 2007

I'll be presenting this technical session on Web Services Security alongwith Marc Chanliau (Director, Product Management, Oracle) in JavaOne 2007. Here are the session details.

Session ID: TS-8131
Session Title: Java Technology and Web Services Security in Action
Track: Services and Integration
Room: Esplanade 304/306
Date: 11-MAY-07
Start Time: 13:30

Summary: In service-oriented architecture (SOA), security and especially identity propagation are among the challenges IT organizations face today. Java EE and Jav SE provide standards and best practices, such as Java Authentication and Authorization Service (JAAS) and Java Authorization Contract for Containers (JACC), to ensure security in the platform, and web services also provide WS-Security standards for achieving secure communication and identity propagation. In this session, you find out how you can achieve identity propagation between services and business processes by using Java technology. The session introduces you to the various security standards of the Java platform and web services and demonstrates them in action by using an end-to-end scenario involving Java SE, Java EE applications (JAX-WS), business processes (BPEL), and the Enterprise Service Bus (ESB). You will see how Java technology-based security can be used in conjunction with WS-Security standards to encrypt, sign messages, and propagate the identity of users between the various actors of a classical SOA-based application.