Oracle Access Manager (OAM) and Oracle WebCenter Suite

I’ve seen a lot of customer activity recently around integrating Oracle Access Manager (OAM) and WebCenter. By integration, I mean protecting WebCenter with OAM so that specific WebCenter access can be governed by OAM policies and single sign-on between WebCenter and other OAM protected web applications is enabled.

Derick Leo recently created a very good tutorial on this integration (specifically OAM and WebCenter Spaces) for Oracle employees. In this post I’d like to walk you through a condensed version of what Derick laid out and add some commentary.

The first thing to realize is that this integration is 95% the same as integrating with any JAVA web application running in Web Logic Server (WLS). You need to install and configure an OAM WebGate on the web server fronting the app server, you need to install and configure the OAM identity asserter on Web Logic, you need to configure policies in OAM to protected the various parts of the application, and you need to configure an appropriate authentication provider in WLS to populate the (JAAS) principals.

The only WebCenter specific parts of the integration are: 1) Setting a flag in the WebCenter startup script that tells WebCenter that it is being fronted by OAM and 2) Understanding the use of JPS (Java Platform Security – A component of OPSS) by WebCenter and the relation between JPS and the Web Logic SSPI.

Prerequisites
We begin by assuming you have installed and working instances of an LDAP directory (OID), OAM, Web Logic Server, and WebCenter Spaces itself.

We will also assume that you have Web Logic integrated with an HTTP web server of your choosing with an OAM WebGate installed on that web server. Here we will specifically assume you are using OHS with the OAM WebGate for OHS and the WLS plug-in for OHS.

OAM Policy Configuration
For purposes of illustration, I will be assuming that you are installing WebCenter Spaces to run under host www.acme .com.

1) Create a policy domain www.acme.com

2) Create a www.acme.com host identifier

3) In the www.acme.com policy domain, create the following protected resources
/owc_wiki/user/login.jz
/owc_wiki/adfauthentication
/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow
/workflow/webcenterworklistdetail/faces/adf.task-flow
/workflow/sdpmessagingsca-ui-worklist
/rss/rssservlet
/owc_discussions/login%21withredirect.jspa
/owc_discussions/login%21default.jspa
/owc_discussions/login.jspa
/owc_discussions/admin
/webcenter/adfauthentication

4) Create the following resources that we will make unprotected, public resources
/webcenter
/owc_wiki
/owc_discussions
/rss
/workflow

5) Create a policy called “Public_URI_Policy” with the following specifics:
Resource Type: http
Resource Operation: Check GET and POST
Resource: Select all resources that you want to unprotect, listed above in step 4.

Under Authentication Rule tab, create a rule with the name Anonymous and authentication scheme OraDefaultAnonAuthNScheme

6) Back under the main www.acme.com policy domain configuration, under the Default Rules tab and the Authentication Rule subtab, create a rule with the name Default_SSO and authentication scheme OraDefaultFormAuthNScheme.

Configure the OID Authentication Provider for Web Logic

Create a new authentication provider called “OIDAuthProvider” of type OracleInternetDirectoryAuthenticator. Set the control flag to “SUFFICIENT” (more on this later).

Fill out the rest of the LDAP specific data under the “provider specific” tab. This is pretty straight forward and no different than a non-OAM WLS configuration that uses an LDAP authentication provider.

Configure the OAM Identity Assserter for Web Logic

Create a new authentication provider called “OAM Asserter” of type OAMIdentityAsserter. Set the control flag to “REQUIRED”.

Ensure that the obssocookie in the “Chosen” column under “Active Types”, then click save.



Next you must click on the provider specific tag of the OAM Asserter and fill out all the required OAM WebGate connection information. This is required because the OAM Id Asserter uses the OAM WebGate API to call the access server to validate the OBSSO token. The values for these should be consistent with the values for the WebGate protecting OHS. Example values are:

Transport: open
Application Domain: www.acme.com
Access Gate Password:
Access Gate Name: www.acme.com_AG
Primary Access Server: a.acme.com:6021
SSO Header Name: OAM_REMOTE_USER

Reorder WLS Providers

The order of the authentication providers in WLS is doubly important here.

First, authentication provider order is something that trips people up very often. It is important to understand the impact of ordering and the relationship between the order and the control flag assigned to each provider (REQUIRED, SUFFICIENT, or OPTIONAL). The WLS doc goes into this subject pretty well so I’ll just refer you to it: http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/atn.htm#SECMG172

The second less obvious impact of the authentication provider order is that it has an impact on WebCenter operations. At times WebCenter needs to query the user store and it does this through the Oracle JPS API and it appears that by default JPS picks up the user store information from the first authenticator in the list in the WebCenter domain. Now, this nuance can be explicitly overridden in the JPS configuration (jps-config.xml). However, it is definitely something to keep in mind.

So with that in mind, reorder the providers so that the OAM ID Asserter is first, followed by the OID Authenticator, and then by the default asserters and authenticators.

Configure WebCenter Spaces for OAM

Lastly, we must make a small tweak to tell WebCenter that it is behind OAM. The most obvious effect of this change is that a different landing/login page is displayed.

To perform the tweak:

1) Shutdown Web Logic
2) Open up the setDomainEnv.sh script located in your WebCenter domain
(/user_projects/domains/workshop_domain/bin/setDomainEnv.sh)
3) Add EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES in an appropriate place in the file in amongst the other similar lines.

4) Restart Web Logic

Testing
When you go to the WebCenter Spaces landing/login page you should now see a login button in the upper right portion of the page rather than the login page itself that you see by default.






The login button will take you to the OAM login form and after providing valid credentials for a Spaces user, you should be able to use the application as before. You should also now be able to sing sign-on between WebCenter and other OAM protected applications, even apps running in containers other than WLS.

Understanding SAML Sender Vouches and WebLogic Server's Use of Certificates

There are two types of certificates involved in SAML Sender Vouches. The identity of the sender and the issuer of the SAML Assertion.

The identity of the sender and their certificate, is configured via the PKICredMapper on the client, and needs to be trusted by the server. This is based on the Trust Store configured for the domain.

The server also needs to sign the response. How the certificate is included in the response is determined by the policy of the web-service producer, and impacts set-up on the client. If you modify the RecipientToken element inside of the policy from this:

<ns1:RecipientToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:RecipientToken>

to this:

<ns1:RecipientToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator">
<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:RecipientToken>

then the web-service will sign the response, and include the raw X.509 certificate. This certificate just needs to be from a trusted CA on the client. Without this modification, then WLS does not send the certificate and references the certificate by issuer's serial number. In this case, you need to set-up the CertificateRegistry and add the actual server's certificate into the client's certificate registry in order to be able to verify the response.

The second type of certificate is for the SAML Assertion, and the signing of the SAML Assertions is not required. Since the WLS CredMapper is actually creating the SAML Assertion and sender-vouches already requires the sender to be trusted, its not clear that signing the certificate adds any actual extra protection.

Writing managable policies in OES

I've been meaning to write this down for quite a while and never had the time to do the subject justice. I'm not sure that I have the time now, or that I've done the subject justice, but this is my attempt to describe the most common mistakes made by new users of OES.

Creating policies in OES is easy. Creating a manageable set of policies is easy too, but it usually requires a bit of forethought.

When you write a Authorization policy in OES you pick from a menu of options to fill in 5 boxes:

1. Effect - one of Grant/Deny/Delegate
   
2. Privilege AKA Action
   
3. Resource
   
4. Subject - user(s), group(s) or Role(s) or some combination thereof
   
5. Constraint
   

The first thing new users of OES do is create a few users in OES' database and then start writing policies directly on those users. Something like

• grant Alice access to Report123
  
• grant Alice access to Report124
  
• grant Alice access to Report125
  
• grant Alice access to Report126
  
• grant Alice access to Report127
  
• grant Bob access to Report123
  
• grant Bob access to Report124
  
• grant Charlie access to Report123

OES supports this sort of deployment and there's nothing actually wrong with using OES with this model.

Well nothing except that it's unmanageable.

Why?

Why shouldn't Charlie have access to Report124? When Charlie gets that big promotion which additional reports does he need permission to access? When we hire Dave which reports does he need to access?

It's much better to write your policies on Roles:

1. grant SupportReps access to Report123
   
2. grant TealLeads access to everything that SupportReps have
   
3. grant TeamLeads access to Report124
   
4. grant SupportManagers access to everything that TeamLeads have
   
5. grant SupportManagers access to Report125, Report126 and Report127
   

If you do things The Right Way these roles are hierarchical - the SupportRep role is below TeamLead which is in turn below SupportManager. This means that rule #2 and #4 go away.

Then you create policies to grant the SupportRep role access to the resources that a support rep needs, etc.

And that's the standard pitch for Role Based Access Control (RBAC)


Once you get your head around RBAC the next logical question is "Is there a standard way to automatically load/maintain users in OES?" (an actual question posted to OTN forums).

The answer is you probably don't need to do that.

Really.

The only things you need to put in OES' user database are those that you want to directly use in an OES policy.

If you have all of your users in an LDAP directory or an existing database then why would you want to replicate all of that into another database? Even with provisioning it's an unnecessary complication since an OES Security Module can be configured to use your existing directory or database simply by configuring the appropriate Authenticator. When a user actually logs in the Authentication Provider will go to your user directory, authenticate the user and gather up all of their group memberships. That information gets stored in the JAAS subject as a list of Principals, and at authorization time the JAAS subject is where OES gets the information it needs about the user.

So in our example if you wanted to create a policy to grant the SupportManager Role to everyone in a group named "SupportManagerGroup" in your LDAP directory then you would need to create a group with the same name in OES' database. You do not need to create the users in the OES GUI or through OES' management APIs. And you certainly don't need to maintain group memberships in OES' policy database.

Actually granting that Role to the existing group of users is trivial - go to the Roles tab in OES click New to create a new Role policy and pick the group off the list.

Doing all of that gets us down to

• grant Alice the SupportManagers Role
  
• grant Bob the TeamLead Role
  
• grant Charlie the SupportRep Role
  
• grant SupportReps access to Report123

grant TeamLeads access to Report124

grant SupportMangers access to Report125, Report126, Report127

But we're not done yet because there's one further simplification possible.

So far we've been talking about Report123, Report124, Report125, Report126, and Report127 as named objects in OES. OES allows you to do that and again there's often absolutely nothing wrong with creating all of those objects in OES directly. If you have a small number of objects or don't add and remove objects often this is perfectly reasonable and easily manageable. But if you have hundreds or thousands of objects or you add and remove objects frequently this can quickly become troublesome.

Objects in the actual application, like Reports, almost always have some metadata. In this example they might contain a Region and Department number. Further let's assume that a user has a single department, and is associated with one or more regions.

A simpler way to express the authorization policy might then simply be to say:

• A user may see reports associated with their department and one of their regions

When you write the policy in OES you pick off the menus

Effect: Grant

Action: view

Resource: //Reports

Subject: Role/SupportRep

and then you enter a constraint that compares the department on the report with the user's department and compares the region on the report with the list of regions associated with the user.

In OES this represented with the syntax:

grant( view, //Reports, //Roles/SupportRep ) if reportDepartment = userDepartment and reportRegion in [userRegions]

So all told we went from eight hard to understand policies to four policies - three to grant roles and one for authorization. And when we hire, fire, promote, demote or do anything else with users we don't have to touch OES.

Problems with Unsigned WS-Security Timestamps in the Response

I've had a few customers recently that have struggled with this scenario - a web-service consumer receives a response message that it cannot validate. We spend some much time focusing on the request, but often don't think about the response. The messages in question look something like this:

<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" S:mustUnderstand="1">
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2009-11-03T10:12:44Z</wsu:Created><wsu:Expires>2009-11-03T10:13:44Z</wsu:Expires></wsu:Timestamp>
</wsse:Security>
</S:Header>
<S:Body>
<ns2:sayHelloResponse xmlns:ns2="http://ws.my/">
<return>
Hello,Josh!
</return>
</ns2:sayHelloResponse>
</S:Body>
</S:Envelope>

The issue is that the message includes a timestamp, but its not signed. I've seen this issue with both WCF clients as well as Oracle Web Services Manager (OWSM).

Depending on the client stack, there are two ways to fix this issue. The first is to simply sign the response. This is really the best practice, especially for a message that the sender took the time and effort to add WS-Security to in the first place. The second approach, is to simply remove the message security (i.e. WS-Security header and timestamp). For example, below is a modified Wssp1. 2-2007-Https.xml that still ensures that the request is over SSL, but removes the "offending" timestamp.

Wssp1. 2-2007-Https-no-timestamp.xml

<?xml version="1.0"?>
<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
  >
  <sp:TransportBinding>
    <wsp:Policy>
      <sp:TransportToken>
        <wsp:Policy>
          <sp:HttpsToken />
        </wsp:Policy>
      </sp:TransportToken>
      <sp:AlgorithmSuite>
        <wsp:Policy>
          <sp:Basic256/>
        </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:Layout>
        <wsp:Policy>
          <sp:Lax/>
        </wsp:Policy>
      </sp:Layout>
    </wsp:Policy>
  </sp:TransportBinding>
</wsp:Policy>

Cloud Security for PAAS and SAAS Use Cases

One of the really interesting things about working in the security area, is that you get to learn about a lot of different technologies. In order to work to integrate/diagnose/optimize security into some container, you have to get a pretty good understanding of that container works. This has created good opportunities for me to learn about a ton of different technologies over the years. But recently, I have to admit, I became a little uneasy when I started preparing for a meeting on securing their cloud.

I know that people use SOA and Cloud and PaaS (Platform as a Service), IaaS (Infrastructure as a Service) and SaaS (Software as a Service) in some what overlapping ways, and I am in no way an expert on "the cloud" and all of the different layers, but there have been two recent use cases, that I'm bundling in this post as "Cloud Security Use Cases".

PaaS Secured By Oracle Identity Management

So, in this case, the Platform is WLS. Imagine adding WLS instances on-demand, and having them pre-configured with applications, or just environment suitable for a certain class of applications. When the domain is configured, what should the security be? In this use case, lets assume that its impractical to have each domain be totally isolated. Isolation in this sense means that all of the security infrastructure is also contained inside of the Node (droplet?) in the Platform cloud. The WebLogic platform needs to make use of a shared Identity Management infrastructure - Web SSO, User Authentication, Audit.

The core security configuration in WebLogic Server for a domain in a realm. Configuring a realm to accept tokens from the Web SSO infrastructure is pretty straight forward - though typically there may be some Web SSO specific configuration like the creation of trust between the PEP and the PDP. Authentication is straight forward as well - all instances point to a common LDAP configuration. The audit configuration is simple as well - either local file audit or configured to point to a centralized service.

Authorization becomes a little more interesting. I think the type of authorization that needs to be configured depends of the requirements of the application(s) running on the domain. If you need basic JEE authorization, contained in the deployment descriptors of the application, you can use the default XACML provider. If you wanted centralized authorization, you'll need to deploy the realm with Custom Roles and Policies, and configured Authorization and Roles providers that support centralized management - like Oracle Entitlements Server (OES). OES administration is performed centrally from the OES admin server, but the policy enforcement can be done either inside of the container (WLS-SM) or from a central service (WebService/RMI-SM). The WLS-SM makes the decisions with lower latency, so its best for applications which require low-latency decisions. The WebService and RMI SM use the same engine and are just as fast, but once you add in the latency of SOAP or RMI, the latency goes up and through-put goes down. Essentialy, from a cloud perspective, you have a few different flavors of platform (JEE Security, Centralized Admin/Centralized Enforcement, Centralized Administration/Local Enforcement)

Obviously, in this model with applications running in the cloud, it would make sense to have the supporting Identity Management technologies running in a cloud as well, but that is a post for another day ;)

More details on using WebLogic and PAAS can be found here

Multi-tenant SaaS Secured By Oracle Identity Management

In this model, the Identity Management pieces are running as part of the application node. Basically, each domain of WebLogic Server uses its own Authenication and Authroization services. This is because each domain represents a unique customer of a service, and in this example, lets assume that there are rules prohibiting the sharing of data across customers. Cloud makes sense here, since its easy to isolate the customers from each other. But, what if a use case arises where their needs to be sharing of information across customers, for example if two customers merge or if several customers work in some sort of partnership.

The answer is to create a new domain for the merged company/partnership and then virtualize the information of each individual partner behind the new entity. This actually can be a pretty elegant solution to what is basically an edge case. 99% of the scenarios in multi-tenancy have customers isolated, but these use cases can add a lot of complexity - example: pushing down the tenant_id filter to the databaase or complexity with LDAP schema design. The preferred alternative here is to try to address these use cases with the cloud directly. In specific, use Oracle Virtual Directory (OVD) to build a unified view of all of the users and ODSI Suite to virtualize the data across the data of each individual partner.

Fortunately, WebLogic Server supports multiple realms, so you can configure a domain with one realm for each type of model you'll need in the cloud, and then you can simply switch the active realm for the domain. This means that once deployed, to change the way that the domain interacts with the Identity Management system can be changed very easily, which is the whole point of putting things in the "cloud" in the first place.

Conclusion

These use csaes are the first that I've seen with actual customers, but I suspect, given all of the excitement around the cloud, that there are more out there. I encourage people to share them on this blog, so that we can have a "grounded" discussion about this topic.

Happy Thanksgiving

Installing OES with WebLogic 11gR1

The below is not officially supported by Oracle yet, but I've been happily running OES under WebLogic 11gR1 and thought it might be useful information for others.

WebLogic Server 10.3 is the most recent version certified for use with OES is 10.1.4.3. If you want to run OES with WebLogic 11gR1 (also known as WebLogic 10.3.1) you will need to take a few extra steps.

1) install WebLogic 11gR1

2) run the DBConfig tool to create the database for OES
3) install OES 10.1.4.3 Admin Server

During the installation do not install the OES schema.

4) install the latest OES cumulative patch - currently CP2

to do this you unzip the patch, edit ApplyAdminPatch.bat or .sh and then run that script

5) run install_schema.bat or .sh depending on platform. This script no only creates all of the tables and indexes but it also loads the default set of policies and boots the server.

If you accidentally install the schema in step 3 it's easy enough to recover:

1) stop SCM and Admin server
2) unzip the latest CP
3) edit the ApplyAdminPatch.sh/.bat
4) apply the patch
5) run install_ales_schema.sh/.bat

Update on Dec 2, 2009: CP3 is now available.

Oracle Access Manager (OAM) and Directory Migration

At times it is necessary to reconfigure one or more of Oracle Access Manager’s directory configuration.

This post describes the recommended process and step-by-step configuration changes to Oracle Access Manager (OAM) required to make OAM utilize a different directory or directory configuration for user, configuration and policy storage.

This post does not address the migration of data between directories themselves. Rather, it focuses on the configuration changes required in OAM.

Also be aware that schema and tree changes can require additional considerations such as requiring changes to attribute access control policies and attribute mapping.

Overview

I recommend that during the process of modifying OAM directory configuration, users turn on directory logging/debugging sufficient enough to monitor all LDAP requests made from OAM to the directory.

If directory changes are being made to the user store and OAM policy/configuration stores then I recommend that OAM users first re-configure the user store by modifying the directory server profiles. I recommend that this change is tested and verified before moving on to modifying the policy/configuration store.

The process for modifying directory configuration in OAM mostly follows what is outlined in the OAM documentation on the subject. However, I would like to make the following clarifications:

1) Directory profile changes themselves are activated following a restart of the OAM services. Changes to directory configuration for policy and configuration storage require re-configuration of the appropriate components (Identity Server, Policy Server, and Access server).

2) In the re-configuration of the Access Server, customers should execute the start_configureAAAServer command with the ‘install’ option rather than the ‘reconfig’ option recommended in the doc. The reconfig option does not give you the opportunity to reconfigure directory configurations. The appropriate command on UNIX is as follows:
start_configureAAAServer install

Directory Profile Changes To Reflect User Store Changes

Directory profile changes can be made from either the Identity or Access System consoles. Directory profiles appear to be shared across OAM components and so only need to be changed in one place.

From the Identity System Console:
1. From the Identity System Console, click System Configuration.
2. On the System Configuration page, click Directory Profiles. The Configure Profiles page appears. The middle section of the page, under the heading Configure LDAP Directory Server Profiles, contains a list of configured directory server profiles.
3. Click the link for the directory server profile that you want to view. The Modify Directory Server Profile page appears.

From the Access System Console:
1. From the Access System Console, click System Configuration, then click Server settings. The View Server Settings page appears. This page displays the directory settings for configuration and policy storage, a link to modify those settings, and a listing of directory profiles with links to modify the profiles as well.
2. Click the link for the directory server profile that you want to view. The Modify Directory Server Profile page appears.

From the Modify Directory Server Profile page, simply make the modifications you desire and then restart all OAM services.

At this point I recommend that you do a test login to verify that the change worked and that users can now be successfully authenticated out of the modified Directory Profile (associated with a new or modified directory).

Modifying Policy and Configuration Data Directory Configuration
1. First modify the Directory Server Configuration in the Identity System Console.
a. From the Identity System Console, click System Configuration. On the System Configuration page, click Directory Profiles. The Configure Profiles page appears.
b. The top portion of Configure Profiles page shows details for the directory server that contains user data and configuration data. Click the Directory Server link to bring up the modification page.
c. Modify the page as you intend. Note that if you change the security, server, or port setting that you will have to rerun the Identity Server setup (see below).

2. Modify the Directory Server Configuration in the Access System Console.
a. From the Access System Console, click System Configuration, then click Server settings. The View Server Settings page appears.
b. Click the Directory Server link to bring up the modification page.
c. Note here that the page is divided into two sections. One section to configure the store for ‘configuration data’ and one section to configure the store for ‘policy data’. Many OAM users will make these the same but they can be different.
d. Modify the page as you intend. After making changes you will have to rerun the setup processes for the Policy and Access Servers (see below).

Rerun Setup for All Components
Rerun the setup of the Identity System, Policy Manager, and Access Server, in order, carefully following the instructions in the documentation (with one exception listed below):

http://download.oracle.com/docs/cd/E15217_01/doc.1014/e12489/idconfig.htm#BABIGBIG

After completing each component, I recommend that you restart that component and verify that on startup it is successfully pulling the appropriate data from the modified source.
As mentioned above, you need to execute the start_configureAAAServer command with the ‘install’ option rather than the ‘reconfig’ option recommended in the doc. The reconfig option does not give you the opportunity to reconfigure directory configurations. The appropriate command on UNIX is as follows:

start_configureAAAServer install

The new Oracle Entitlements Server (OES) and Oracle Web Services Manager (OWSM) 11g integration is finally here!

I know that a lot of people have been after me for this, so I want to apologize again for how long it has taken me to get this together (OOW + 3 weeks). But I hope people find it worth the wait.

This is essentially an update of some work that Kamlesh Patel did last year, so the basic design is really his idea.

OES-OWSM Integration FAQ

Question:Where can I get it?

Answer: I added to the OWSM 11g Custom Assertions Project on www.samplecode.oracle.com.

Question:What are the prerequisites?

Answer: You'll need an 11g SOA Suite Domain protected by an OES WLS SM. What I did for the OOW demo that makes things a lot simpler is use the OESAdjudicator. I talked a little about this approach previously. Basically, follow the steps I outline before except that instead of throwing the domain into discovery mode and figuring out the WLS resources, just add the OESAdjudicator to the domain. This basically eliminates the need for OES to protect the WLS resources.

Question: How do I build it?
Answer: You'll need to get the source code from svn. The details are here.
The src and the build are contained in the oes-owsm directory. You'll need to modify the build.xml file to point to the SOA home and OES home directories. From there, set-up you're environment (BEA_HOME/wlserver_10.3/server/bin/setWLSEnv.cmd) and then run ant. You should end-up with a file called oes-owsm.jar.

Question:Why do I need to know how to build it?

Answer:Because when you use it to protect a WLS Web Service, all of the configuration is contained in the META-INF/policies/samples/oes file, and this needs to be packed into the jar. I have not tested this custom assertion protecting SOA Composite Web Services

Question: What can I configure in the META-INF/policies/samples/oes file?

Answer: Let's take a look at the file

<wsp:Policy xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orasp="http://schemas.oracle.com/ws/2006/01/securitypolicy"
orawsp:status="enabled" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" orawsp:category="security" orawsp:attachTo="binding.server" wsu:Id="oes_authorization_policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
wsp:Name="sample/oes">

           <orasp:oes orawsp:Silent="true" orawsp:Enforced="true" orawsp:name="OES Authorization" orawsp:category="security/authorization">
            <orawsp:bindings>
                  <orawsp:Implementation>com.oracle.oes.owsm.sample.Assertion</orawsp:Implementation>
                  <orawsp:Config orawsp:name="oes" orawsp:configType="declarative">
                        <orawsp:PropertySet orawsp:name="OES RMI SSM Settings">
                              <orawsp:Property orawsp:name="ConfigDirectory" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>c:/bea/ales32-admin/rmi-ssm/instance/rmissm/pdpproxy</orawsp:Value>
                              </orawsp:Property>
                              <orawsp:Property orawsp:name="ConfigID" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>soa_suite_domain2</orawsp:Value>
                              </orawsp:Property>
                              <orawsp:Property orawsp:name="AuthenticationRequired" orawsp:type="boolean" orawsp:contentType="required">
                                    <orawsp:Value>false</orawsp:Value>
                              </orawsp:Property>
                        </orawsp:PropertySet>
                        <orawsp:PropertySet orawsp:name="OES Identity Assertion Settings">
                              <orawsp:Property orawsp:name="InternalAssertion" orawsp:type="boolean" orawsp:contentType="required">
                                    <orawsp:Value>false</orawsp:Value>
                              </orawsp:Property>
                              <orawsp:Property orawsp:name="OWSMIdentity" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>OWSM</orawsp:Value>
                              </orawsp:Property>
                        </orawsp:PropertySet>
                         <orawsp:PropertySet orawsp:name="OES Authorization Settings">
                              <orawsp:Property orawsp:name="Application" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>owsm</orawsp:Value>
                              </orawsp:Property>
                              <orawsp:Property orawsp:name="Resource" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>oow2009demo</orawsp:Value>
                              </orawsp:Property>
                              <orawsp:Property orawsp:name="LookupAction" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>lookup</orawsp:Value>
                              </orawsp:Property>
                              <orawsp:Property orawsp:name="ExecuteAction" orawsp:type="string" orawsp:contentType="required">
                                    <orawsp:Value>execute</orawsp:Value>
                              </orawsp:Property>
                        </orawsp:PropertySet>
                   </orawsp:Config>
             </orawsp:bindings>
      </orasp:oes>
</wsp:Policy>

There are only a few properties that you need to really care about. ConfigID is the name of the realm that WLS is running - I think the configTool makes it the domain name, but look in config.xml just to be sure. Application and Resource are concatenated together to make up the prefix for the resource in OES. Example: //app/policy//owsm/oow2009/model object name/port name

Question: How do I install it?

Answer: Copy the oes-owsm.jar to the DOMAIN_HOME/lib directory, and restart the server.

Question: How do I bind it to a webservice?

Answer: You add it to policy just like any other WLS Web-Services policy. Either through the WLS console or through the @Policy annotation. Note: You need to configure an additional policy that does the actual authentication, like one of the SAML policies. The assertion assumes that the user is already authenticated. Also, again I haven't tested it attaching it to a SOA composite, but if some one wants to try, I'll support the effort ;)

Question: How do I author an OES policy using it?
Answer: Take a look at the policies from my OOW demo



I modeled it as a two step process (I could have just as easily passed down the entire SOAP message to the WLS SM, like I did in the OES-BPEL integration, but I think for most in-bound authorization cases, I like this model). In the first step, the assertion calls OES with the lookup action. If it succeeds, it processes the responses in an interesting way. If the response has a name of namespace then it sets uses it as the target name space for the XPathQuery. If its anything else, then the Assertion assumes that the name of the response is a dynamic attribute, and the value is an XPathQuery that the assertion should run to populate the attributes.

In the example for OOW, there are two responses from the lookup. One to get the value of the CCType in the body and add it to the variable oow_cc_type. The other is pulling the value of the attribute title from the AttributeStatement from the SAML Assertion (basically, the user's title) and sets it in the oow_title attribute.

The execute action gets called next and basically, as you can see from the example, passes in the values it got from the lookup XPATHQuery.

Question: What do I do if I want to use a namespace other than tns,env, or saml?

Answer: You need to add it to modify the AssertionNamespaceContext.java to handle the namespace. The code is pretty simple.

  public String getNamespaceURI(String prefix) {
    System.out.println("Looking for the namespace for prefix: "+prefix);
    
    if (prefix.equals("env")) {
      
      return "http://schemas.xmlsoap.org/soap/envelope/";
      
    } else if (prefix.equals("saml")) {
      
      return "urn:oasis:names:tc:SAML:1.0:assertion";
      
    }
    
    return theNamespace;
  }

So What Next?

I added the project (like most of my stuff from the blog) to http://soa-security.samplecode.oracle.com. Try this out, and let me know what you think, but also, this integration could be enhanced in a number of ways. Examples:

• What should OES do when filtering the response?
  
• What could OES do with responses if it knew that the Web Service has a DataControl (i.e. SOAP Message contains a query)?
  

The source is out there, so I'm hoping people will add their own contributions. Basically, I hope that I've taught you how to fish. If you are starving, just post a comment here, and we'll throw you a fish stick :)

WebLogic Server (WLS) to Oracle Service Bus (OSB) to WebLogic Server using SAML Sender Vouches - Active/Active

In yesterday's post on WLS to OSB to WLS with SAML Sender Vouches, OSB was not really acting as a full "active-intermediary". Basically, OSB was validating the SAML Assertion on the request and sending a new request with a new SAML Assertion to the business-service. The response from the business service (though signed) was ignored by OSB. The signature is validated by the sender. Let's for the sake of discussion call this configuration active/passive security. This model works if:

• You are basically interesting in using OSB to authorize the use of services
  
• You are not doing any transformations on the response (you'll break the signature).
  
• The producer and consumer trust each other directly. This is different then they each trust the service bus.
  

If your deployment meets this criteria, then "Bob's Your Uncle" (I'm from Massachusetts, not California, so I'm not sure I used that right - but basically I'm saying "you're good")

If not, then read on. These are the gory details of getting this scenario to work in active/active. I'm not going to cover everything from yesterday, I'll just get down to the brass tacks of the policies.

Direction.In (Request)

• WLS Service Consumer - Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml(Standard)
  
• OSB Proxy Service - OSB SAML Sender Vouches (Standard)
  
• OSB Business Service - OSB SAML Sender Vouches plus Sign Timestamp (Custom)
  
• WLS Service Producer - Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml minus ProtectTokens (Custom)
  

Direction.Out (Response)

• WLS Service Consumer - Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml minus ProtectTokens plus Include Recipient Token (Custom)
  
• OSB Proxy Service - OSB Sign.xml (Standard)
  
• OSB Business Service - OSB "Empty" Policy (Custom)
  
• WLS Service Producer - Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml minus ProtectTokens (Custom)
  

Configuring the WLS Service Producer

Since this is a use case primarily about processing the response, let's start with the response coming back from the service producer. OSB cannot handle <ProtectTokens> policy assertions because it does not support the STR Transform that WLS uses to generate the signature. So, this assertion has to be removed from the standard Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml.

Configuring the Business Service

A nuance of the way that OSB enforces policy is that the entire message is processed - signatures validated, messages decrypted - and then the policy is checked to see if it complies. The policy is basically a minimum that has to be met - not a prescription for how to validate the message. The idea of the "Empty" policy is to just have OSB process the signature that the Service Producer generated. There are no other conditions.

Configuring the Proxy Service

The message now needs to be signed by OSB. The pre-configured Sign.xml will work just fine.

Configuring WLS Service Consumer

You need to use two different policies for the JAX-WS client. Since the signature generated by OSB does not conform with the standard policy in two ways - it does not protect the tokens (sign) and it does include the RAW X.509 Certificate as opposed to an reference by Issuer Serial Number. So, the policy for the outputMessage (outbound) is a custom policy very similar to the in-bound policy on the service consumner, except that we have to additionally allow for the Recipient Token to be passed. The policy for the inputMessage (inbound) is the standard Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml. The code looks like this:

        ClientPolicyFeature cpf =
            new ClientPolicyFeature();
        
        InputStreamPolicySource ps_out = new InputStreamPolicySource(this.getServletContext().getResourceAsStream("/WEB-INF/policy-no-protect-plus-recipient-token.xml"));
        InputStreamPolicySource ps_in = new InputStreamPolicySource(this.getServletContext().getResourceAsStream("/WEB-INF/policy.xml"));
        
        cpf.setEffectivePolicyForInputMessage(ps_in);
        cpf.setEffectivePolicyForOutputMessage(ps_out);
        
        Dispatch<SOAPMessage> dispatch = service.createDispatch(portName, 
                                                                SOAPMessage.class, Service.Mode.MESSAGE, new WebServiceFeature[] {cpf});
        
        
        
        SOAPMessage response = dispatch.invoke(request);

Policies

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml minus ProtectTokens

<?xml version="1.0" encoding="windows-1252" ?>
<wsp:Policy wssutil:Id="Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml" xmlns:wssutil="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<ns1:AsymmetricBinding xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns1:InitiatorToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:InitiatorToken>
<ns1:RecipientToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:RecipientToken>
<ns1:AlgorithmSuite>
<wsp:Policy>
<ns1:Basic256 />
</wsp:Policy>
</ns1:AlgorithmSuite>
<ns1:Layout>
<wsp:Policy>
<ns1:Lax />
</wsp:Policy>
</ns1:Layout>
<ns1:IncludeTimestamp />

<!-- OSB does not work well with this assertion
<ns1:ProtectTokens />
-->

<ns1:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</ns1:AsymmetricBinding>
<ns2:SignedSupportingTokens xmlns:ns2="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns2:SamlToken ns2:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<ns2:WssSamlV11Token10 />
</wsp:Policy>
</ns2:SamlToken>
</wsp:Policy>
</ns2:SignedSupportingTokens>
<ns3:Wss10 xmlns:ns3="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns3:MustSupportRefKeyIdentifier />
<ns3:MustSupportRefIssuerSerial />

</wsp:Policy>
</ns3:Wss10>
</wsp:Policy>

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml minus ProtectTokens plus Include Recipient Token

<?xml version="1.0" encoding="windows-1252" ?>
<wsp:Policy wssutil:Id="Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml" xmlns:wssutil="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<ns1:AsymmetricBinding xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns1:InitiatorToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:InitiatorToken>
<ns1:RecipientToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator">

<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:RecipientToken>
<ns1:AlgorithmSuite>
<wsp:Policy>
<ns1:Basic256 />
</wsp:Policy>
</ns1:AlgorithmSuite>
<ns1:Layout>
<wsp:Policy>
<ns1:Lax />
</wsp:Policy>
</ns1:Layout>
<ns1:IncludeTimestamp />

<!-- OSB does not work well with this assertion
<ns1:ProtectTokens />
-->

<ns1:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</ns1:AsymmetricBinding>
<ns2:SignedSupportingTokens xmlns:ns2="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns2:SamlToken ns2:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<ns2:WssSamlV11Token10 />
</wsp:Policy>
</ns2:SamlToken>
</wsp:Policy>
</ns2:SignedSupportingTokens>
<ns3:Wss10 xmlns:ns3="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns3:MustSupportRefKeyIdentifier />
<ns3:MustSupportRefIssuerSerial />

</wsp:Policy>
</ns3:Wss10>
</wsp:Policy>

Empty Policy

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  wsu:Id="validate-bs-response"
  >


  <wssp:MessageAge/>

</wsp:Policy>

Sender Vouches plus Sign Timestamp

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  wsu:Id="saml-policy-to-business-service"
  >

  <wssp:Identity>
    <wssp:SupportedTokens>
      <wssp:SecurityToken  TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
        <wssp:Claims>
          <wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
        </wssp:Claims>
      </wssp:SecurityToken>
    </wssp:SupportedTokens>
  </wssp:Identity>

  <wssp:Integrity>

    <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <wssp:CanonicalizationAlgorithm 
         URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

    <wssp:Target>
      <wssp:DigestAlgorithm 
           URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
           Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
           wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm 
           URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
          Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
          wsp:GetHeader(./wsse:Security/wsu:Timestamp)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts
           Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
           wls:SecurityHeader(Assertion)
      </wssp:MessageParts>
    </wssp:Target>

  </wssp:Integrity>

  <!--
  <wssp:Confidentiality>

    <wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

    <wssp:Target>
      <wssp:EncryptionAlgorithm 
           URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <wssp:MessageParts
           Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
            wls:SecurityHeader(Assertion)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:EncryptionAlgorithm
           URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <wssp:MessageParts 
           Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
           wsp:Body()</wssp:MessageParts>
    </wssp:Target>

    <wssp:KeyInfo />
  </wssp:Confidentiality>
  -->

  <wssp:MessageAge/>

</wsp:Policy>

  <wssp:MessageAge/>

</wsp:Policy>

Standard OSB SAML Sender Vouches

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  wsu:Id="saml-policy"
  >

  <wssp:Identity>
    <wssp:SupportedTokens>
      <wssp:SecurityToken  TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
        <wssp:Claims>
          <wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
        </wssp:Claims>
      </wssp:SecurityToken>
      <!--
      <wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
      -->
    </wssp:SupportedTokens>
  </wssp:Identity>

  <wssp:Integrity>

    <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <wssp:CanonicalizationAlgorithm 
         URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

    <wssp:Target>
      <wssp:DigestAlgorithm 
           URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
           Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
           wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>

    
    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts
           Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
           wls:SecurityHeader(Assertion)
      </wssp:MessageParts>
    </wssp:Target>
  

  </wssp:Integrity>

  <!--
  <wssp:Confidentiality>

    <wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

    <wssp:Target>
      <wssp:EncryptionAlgorithm 
           URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <wssp:MessageParts
           Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
            wls:SecurityHeader(Assertion)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:EncryptionAlgorithm
           URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <wssp:MessageParts 
           Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
           wsp:Body()</wssp:MessageParts>
    </wssp:Target>

    <wssp:KeyInfo />
  </wssp:Confidentiality>
  -->

  <wssp:MessageAge/>

WebLogic Server (WLS) to Oracle Service Bus (OSB) to WebLogic Server using SAML Sender Vouches

I'm sure many people were hoping that the next post would be the much anticipated OES-OWSM Custom Assertion, but things have been very busy coming out of Open World. Oddly, I'm working with multiple customers that have been looking for a solution to the following use case:

WLS makes a Web-Services call using JAX-WS to Oracle Service Bus (OSB) passing the identity of the caller using SAML Sender Vouches (SV). OSB serves as an active-intermediary and process the SAML Assertion. OSB then goes and calls a Business Service propagating the user's identity, again using SAML SV.

What makes this use case a little tricky is that OSB at present does not understand WS-Policy 1.2 Assertions, and the JAX-WS stack on WLS does not understand the OSB proprietary assertions. This means that local policy needs to be applied 4 places

• JAX-WS Client using WS-Policy 1.2
  
• OSB Proxy Service using OSB Policy
  
• OSB Business Service using OSB Policy
  
• WLS Web Services service using WS-Policy 1.2
  

This post will cover the specific policies and how to apply them at each point.

JAX-WS Client using WS-Policy 1.2

You need to use a ClientPolicyFeature, and load the actual policy from an InputStream. In the example below, I'm running inside a web-application and packaged the policy.xml in the WEB-INF directory.

ClientPolicyFeature cpf =
         new ClientPolicyFeature();
  
  
  
     InputStreamPolicySource ps = new InputStreamPolicySource(this.getServletContext().getResourceAsStream("/WEB-INF/policy.xml"));
  
     cpf.setEffectivePolicy(ps);
  

     Dispatch dispatch = service.createDispatch(portName,
                                                             SOAPMessage.class, Service.Mode.MESSAGE, new WebServiceFeature[] {cpf});
  

The policy that I'm using is just the standardWssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml.

<?xml version="1.0" encoding="windows-1252" ?>
<wsp:Policy wssutil:Id="Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml" xmlns:wssutil="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<ns1:AsymmetricBinding xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns1:InitiatorToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:InitiatorToken>
<ns1:RecipientToken>
<wsp:Policy>
<ns1:X509Token ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

<wsp:Policy>
<ns1:WssX509V3Token10 />
</wsp:Policy>
</ns1:X509Token>
</wsp:Policy>
</ns1:RecipientToken>
<ns1:AlgorithmSuite>
<wsp:Policy>
<ns1:Basic256 />
</wsp:Policy>
</ns1:AlgorithmSuite>
<ns1:Layout>
<wsp:Policy>
<ns1:Lax />
</wsp:Policy>
</ns1:Layout>
<ns1:IncludeTimestamp />

<ns1:ProtectTokens />
<ns1:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</ns1:AsymmetricBinding>
<ns2:SignedSupportingTokens xmlns:ns2="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns2:SamlToken ns2:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<ns2:WssSamlV11Token10 />
</wsp:Policy>
</ns2:SamlToken>
</wsp:Policy>
</ns2:SignedSupportingTokens>
<ns3:Wss10 xmlns:ns3="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<ns3:MustSupportRefKeyIdentifier />
<ns3:MustSupportRefIssuerSerial />

</wsp:Policy>
</ns3:Wss10>
</wsp:Policy>

On the client, beside setting up the policy, you'll also need to configure a SAMLCredentialMapper and a PKICredentialMapper. The PKICredentialMapper needs to have access to a keystore that contains the Private Key used to sign the request.

OSB Proxy Service using OSB Policy

The OSB policy is really just the WLS 9.2 Web Services stack.. Basically, you need to create a WS-Policy and attach it to the request in the proxy service. Also, need to make sure to configure the proxy service to process the WS-Security header.

The actual policy is below.

<?xml version="1.0"?>

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
wsu:Id="saml-policy"
>

<wssp:Identity>
 <wssp:SupportedTokens>
   <wssp:SecurityToken  TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
     <wssp:Claims>
       <wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
     </wssp:Claims>
   </wssp:SecurityToken>
 </wssp:SupportedTokens>
</wssp:Identity>

<wssp:Integrity>

 <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
 <wssp:CanonicalizationAlgorithm
      URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

 <wssp:Target>
   <wssp:DigestAlgorithm
        URI="http://www.w3.org/2000/09/xmldsig#sha1" />
   <wssp:MessageParts
        Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
        wsp:Body()
   </wssp:MessageParts>
 </wssp:Target>

 <wssp:Target>
   <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
   <wssp:MessageParts
        Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
        wls:SecurityHeader(Assertion)
   </wssp:MessageParts>
 </wssp:Target>

</wssp:Integrity>


<wssp:MessageAge/>

</wsp:Policy>

Setting up OSB to consume the SAML Assertion and validate the signature requires the creation of a SAML Identity Asserter. NOTE: In the asserting party configuration, OSB uses a relative path Remember this if you run into trouble getting OSB to understand the assertion.

OSB Business Service using OSB Policy

This was really the only "tricky" part. I had to modify the saml-sv policy to sign the timestamp. The policy on the business service doesn't require it, but it does expect the Timestamp to have a wsu:Id, and making OSB sign it does exactly that. The set-up in OSB is the same as the proxy service, just configure the policy on the request.

The policy on the business service is as follows:

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  wsu:Id="saml-policy-to-business-service"
  >

  <wssp:Identity>
    <wssp:SupportedTokens>
      <wssp:SecurityToken  TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
        <wssp:Claims>
          <wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
        </wssp:Claims>
      </wssp:SecurityToken>
    </wssp:SupportedTokens>
  </wssp:Identity>

  <wssp:Integrity>

    <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <wssp:CanonicalizationAlgorithm 
         URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

    <wssp:Target>
      <wssp:DigestAlgorithm 
           URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
           Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
           wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm 
           URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
          Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
          wsp:GetHeader(./wsse:Security/wsu:Timestamp)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts
           Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
           wls:SecurityHeader(Assertion)
      </wssp:MessageParts>
    </wssp:Target>

  </wssp:Integrity>

  <wssp:MessageAge/>

</wsp:Policy>

When adding a business service that requires signing, the proxy service has to have a Service Key Provider. This is really just a wrapper around the policies stored in the PKI Mapper. Basically, you select an alias to use to sign the message going to that business service.



Inside of the realm, in order to be able to configure a Service Key Provider, the PKI CredMapper needs to exist. In addition, the SAML Credential Mapper is required to generate the SAML Assertion.

WLS Web Services service using WS-Policy 1.2

This is pretty straight forward.

@WebService
@Policy(uri = "policy:Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml")
public class Test {
    
    
    public String hello(String in) {
        System.out.println("=====>"+in);
        return "Hello "+in;
    }
    
}

Summary

In setting up a scenario as complicated as this there will undoubtedly be challenges. Use the debug settings inside of WLS, they are your friend. In my set-up I added the following JAVA_OPTIONS to my setDomainEnv.cmd

set JAVA_OPTIONS=%JAVA_OPTIONS% %JAVA_PROPERTIES% -Dwlw.iterativeDev=%iterativeDevFlag% -Dwlw.testConsole=%testConsoleFlag% -Dwlw.logErrorsToConsole=%logErrorsToConsoleFlag%
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.wsee.verbose=* -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true -Dweblogic.xml.crypto.encrypt.verbose=true -Dweblogic.xml.crypto.dsig.debug=true-Dweblogic.xml.crypto.dsig.verbose=true -Dweblogic.wsee.security.debug=true -Dweblogic.wsee.security.verbose=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.wss.debug=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.wss.verbose=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.keyinfo.debug=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.keyinfo.verbose=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.dsig.debug=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.dsig.verbose=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.encrypt.debug=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.xml.crypto.encrypt.verbose=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.servlet.DIEnabled=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAMLService=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAMLCredMap=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAMLAtn=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAMLLib=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAML2Service=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAML2CredMap=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAML2Atn=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecuritySAML2Lib=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.debug.DebugSecurityCredMap=true

This gives you good visibility into where the issues are. Also can't hurt to have the weblogic.security.atn and weblogic.security.credmap debug categories on. When trying to figure out what is going on, more information is better. Be patient, this will spit out a lot of information, but look through it and you can normally get to the issue.

JSF and OES part 3

The third in an ongoing series of posts on securing a JSF based app (in this case using ADF components).

In the part 1 I plugged OES' Security Module into WebLogic Server. In part 2 I showed how to deploy the app and write OES policies to secure URLs and other objects that WebLogic automatically protects. In this post I'm going to rely on the small chunk code of I provided in a post that discussed calling OES from inside a J2EE app. If you haven't seen that post you should probably at least skim through it and grab the code.

If you have an existing JSF based application you probably already have some security logic embedded in it today. In my experience the most common way that people to do that in JSF seems to be abstracting all of that code into a bean and then setting the rendered or enabled attribute to an EL expression that invokes the authorization bean.

What I mean is that the bean has a method to get a boolean value like MaySeePatients:

public class AuthorizationBean {
   public boolean getMaySeePatients() {
    // everyone can see patients so I return true
       return true;
   }
}

You tell JSF to creating and manage an instance of the bean for you by defining it in faces-config.xml

   Authorization
   com.oracle.demo.drapp.view.backing.AuthorizationBean
   session

And then in your JSF you would call the bean with something like this:

Swapping out the existing authorization logic to use OES instead is simple - add that ALESControl code I shared in my previous post and edit your bean to call OES.

Your bean then looks like this:

public class AuthorizationBean {
   public boolean getMaySeePatients() {
       AZRequestHandler az = new AZRequestHandler("view", "Patient");
       return az.isAuthorized();
   }
}

JSF provides a few other simple ways to call this logic, for example c:choose which implements if/then/else logic

Simple, huh?

Unfortunately while all of this makes it easy to protect your JSF application with OES, it relies on the developer (a) knowing what to secure and (b) properly calling the security system. Part of the point of OES is that once you plug it into your application you get a bunch of stuff secured automatically and if you need to secure anything else later you don't have to change the source code to the application.

So how do we do that?

Stay tuned!

JAVA Key Stores for SOA Security

In a how-to post on SAML OWSM client policies last month, Josh mentioned how he used separate “Alice and Bob” keystores for the client and the service. I think this is a very important notion and would like to expound upon it in this post.

I see too many people building out SOA development and test environments that utilize a single key store for all the components in their environment. Even worse, I see lots of people utilizing the same key and certificate pair for every component in their environment. If your environment is a dev/test environment built on Oracle products, this is likely the ever-popular “orakey” pair.

I believe that it is important to utilize separate keystores and key-certificate pairs for the client, service, and any intermediary components where keys and certificates are required in your development and test environments.

Taking the short cut of having components share keystores and even key-certificate pairs will only burn you down the road as you move forward with the development of your services and applications. Sharing keys and keystores can mask potential issues that will appear when you try to setup real keystores as you approach production. Further, sharing keys and keystores can actually make it more difficult to diagnose and solve certain issues that can occur during the build out and configuration of an environment.

I will now walk you though the simple steps of creating properly configured client “Alice” and service “Bob” keystores using the Oracle CertGen and ImportPrivateKey utilities. Following these steps you can have proper test keystores ready to go in a matter of minutes.

1) Create client (Alice) key-certificate pair signed by the demo CA cert "CertGenCA"

>> java utils.CertGen -certfile AliceCert -keyfile AliceKey -keyfilepass password

2) Create service (Bob) key-certificate pair signed by the demo CA cert "CertGenCA"

>> java utils.CertGen -certfile BobCert -keyfile BobKey -keyfilepass password

3) Create client (Alice) keystore with client key-certificate pair

>> java utils.ImportPrivateKey -certfile AliceCert.der -keyfile AliceKey.der -keyfilepass password -keystore Alice.jks -storepass password -alias alice -keypass password

4) Create service (Bob) keystore with client key-certificate pair

>> java utils.ImportPrivateKey -certfile BobCert.der -keyfile BobKey.der -keyfilepass password -keystore bob.jks -storepass password -alias bob -keypass password

5) Now add the root CA to both stores

>> keytool -importcert -file CertGenCA.der -keystore Alice.jks

>> keytool -importcert -file CertGenCA.der -keystore bob.jks

6) Add bob's public cert to Alice's store. This is needed to configure the recipient alias on the client

>> keytool -importcert -file BobCert.der -alias bob -keystore Alice.jks

7) Use and prosper!

Oracle Entitlement Server patches

I've gotten quite a few questions about where to find the OES patches on Metalink and thought it better to publish publicly.

To get OES CP2 login to metalink and then select in order:

• Patches and Updates
• Quick Links to: Latest Patchsets, Mini Packs and Maintenance Packs
• Oracle Entitlements Server
• MS Windows 32 bit
• 10g R3

Obviously if you want Linux or Solaris patches swap that for Windows.

Also don't forget when installing OES that you have to have a static IP address for the admin server. You can probably do an install on a DHCP enabled host but the next time you get a new IP address everything will go sideways.

--

Update: As of April 2010 CP4 is now available and is recommended for all users using OES.

What is SOA Security?

This question has come up in a few contexts lately. One interesting example was the recent creation of the soa-security sub category on samplecode.oracle.com . There is no multiple inheritance on the site, so it has to either go into security or soa. This begs the question "Is SOA security anything more than just regular security?" Regular security in this context means web-services security - authentication, authorization, audit etc for web-services. Admittedly, on this blog, we spend a lot of time discussing the mechanics of applying these types of controls to web-services in various products and architectures, but is that all that SOA security is?

Part of the success of this blog has been that its pretty much "manifesto-free", so I'll try to stay focused - the often overlooked area of SOA security is design time governance. Most services are not exposed on the public network. The security for the services at runtime is provided by simply being on the intranet, behind the firewall. We've discussed this before around the use of SAML Bearer confirmation method. The bigger issue is how to ensure that people are selecting the right services to use from the UDDI registry, and only those which they (either the developer of the application) is authorized to use. I think the notion of design time SOA security (often called SOA governance) is nicely discussed here, by Bob Rhubart.

There are some things about services and how they are composed and reused in SOA that need to be managed. How much design time governance (i.e. restrictions) obviously varies from environment to environment. I worked with one customer - that I saw again at OOW a few days ago - who pointed me to the the trustcom project. This is a project being looked at by European government agencies, and "frictionless commerce" with SOA. It is pretty dense stuff, but basically consider the concept of creating a virtual organization to go a perform a business (BPEL) process. A BPEL process has roles, so essentially you want to do is select a service provider for each role and then very easily swap providers in and out if for example, the provider is not meeting their SLAs. So when composing this process, you want to make sure that you're always using the "right" provider. So to do this, you need to look them up in the repository of which contains many, many service providers. So, the UDDI registry or repository needs to restrict access to only the members of the Virtual Organization and their services. There are obviously runtime implications to this model as well, but it does illustrate some of the interesting design time decisions around SOA Security (Governance)

Presenting at OpenWorld is an experience

Actually even attending OpenWorld is an experience. I've been to plenty of tech conferences before but OpenWorld is unlike anything I've seen.

Everything about the conference is big - the number of attendees, exhibitors, sessions, even the number of venues since we took over Moscone North, South and West plus the Marriott across the street and the Hilton. The shear number and breadth of the content was astounding and I'm looking forward to taking advantage of the replays.

Beyond the actual size there's all sorts of attention to detail... Things like blocking off a street for tents for lunch and convenience between Moscone North and South, providing free food & drinks in the exhibit halls, running busses from all of the area hotels to the Moscone. And then, just to say thank you to our customers there was a concert on Wed night with Aerosmith, Roger Daltrey, the Wailers and Three Dog Night.

I managed to get to the keynotes from Scott McNealy, Michael Dell, and Thomas Kurian but was in a customer meeting during Larry's and will have to catch it on replay. From what I've seen on Twitter, blogs and press releases he shared the stage with The Governator, talked about the Exadata V2 box, introduced Fusion Apps (the first enterprise apps built on a modern middleware platform) and a bunch more.

And then there's the actual sessions...

In what I'm sure was a complete mistake someone approved me to do a session on securing WebLogic applications. Naturally I should never be trusted to do something like that on my own so April, the OES product manager, and I did the presentation together.

The session was standing room only and atypically for technnical presentations the entire thing went off without a hitch. April did the slide show and then I ran through a demo. Since we had a strict time limit I decided to use a recording of the demo rather than doing it live. I had the live system ready if people wanted us to go off the script or dig into unexpected areas and I wound up using it to show people the code behind the scenes. The recording turned out to be a great idea since it freed me from having to remember which username to log in with and let me focus on what was actually happening and keep a closer eye on people's reactions.

The core take away from our presentation was that if you have J2EE apps deployed on WebLogic Server you should take a very close look at two other Oracle products - OAM and OES. OAM gives you single sign-on across all of your apps including both home grown and shrink wrapped. Web SSO is a well known technology, is pretty widely deployed and, I don't recall anybody in the audience asking any questions about that.

OES was a whole 'nother story. There were questions about nearly every aspect of OES including details of the components, the policy model, how it integrates into WebLogic, what the app server protect automatically, how it's used in an app, and of course licensing questions. April fielded a few questions about integrations with other products I'd not even heard of before and then we ran out of time. After we were kicked out of the room I spent another 20-30 mins in the hallway showing people various aspects of the GUI and answering even more questions about the product. All in all I couldn't have asked for a better experience with my first session.

Unfortunately after the presentation was over and I was headed over to get a bite to eat with Josh I realized that I'd completely forgotten to put a link to the blog! If you're reading this after attending my session thanks for making the effort to find me here!

OOW 2009 Presentation Questions

Thanks to everyone who attended our session yesterday. I'll be posting a recording of the demo shortly, but wanted to share a few questions from the audince.

"Can you apply OWSM policies at the operation level or only at the endpoint level?"

So, in contract to the existing WLS @annotation model, you can only apply policy at the endpoint level. Authorization can be done from within that policy based on the authorization, as we showed with the OES-OWSM custom assertion

"How is the SAML Assertion generated and consumed?"

The SAML is generated from within the OOTB OWSM SAML Assertion (policy assertion). It uses configuration information defined in the jps-config.xml - like the name of the issuer. The SAML is validated by the login module - but this is a different login module then the SAMLAuthenticator or SAML capabilities of native WLS.

These are not meant as dings against OWSM. As a long time WLS Security guy, I've become very pleased with the simplicity and ease of configuration that is provided by OWSM. I also really like the extensibility of the custom assertions - allows you to plug in deep inside of the web-services stack, and that is going to be handy at a TON of customers.

"What is the difference in positioning between OWSM and OSB?"

I think that the decision of when to use OWSM and when to use OSB goes well beyond the security capabilities. I think that there are some use cases around where using the SAML (partner management) capabilities of the WLS stack that is available with OSB would make sense, but this has to be weighed against the fact that OSB uses the WLS 9.2 Web Services stack.

I think that OWSM should not be confused with a full service bus. OWSM is a policy management layer for Web Services....OSB is way more than that.

Update on samplecode.oracle.com

After some discussions with the OTN people, we decided that soa-security is not a project, but rather a category (ok, a sub-category under soa). I created a new project under the soa-security category

OES SSPI Providers

The thinking is to use this project for WLS SSPI plug-ins that we use that are OES specific. The two I have in mind are:

• OESBPELAuditor - the ability to audit changes to the OES policies are store them in XML, such that a BPEL process could consume the changes
  
• OESAdjuductor - the previously mentioned adjudicator that makes integrating the OES WLS-SM more straight forward, but only apply OES decisions to OES resources and XACML decisions to WLS resources.
  

Seems likely that OWSM custom steps and assertions could also make a home in the soa-security sub category. As always, I'm open to suggestions, and I'm sure that this will evolve over time. Most of security is a configuration and administration problem, but there are occasions when some coding is required, and now by using samplecode.oracle.com, there is a vehicle to get this information out.

Oracle Service Bus: Pass-Through vs. Active Security

I was talking to a customer about inserting the Oracle Service Bus (OSB) into their SOA infrastructure. The customer was prepared for a lengthy effort to get OSB to forward the SAML assertion sent from the client on to the service.

However, the fact is, the security functionality in OSB supports this use case exactly and with minimal effort.

The processing of message level security headers can be handled in two distinct ways in OSB: Pass-Through and Active Intermediary modes.

As an active intermediary, OSB processes the security headers in the SOAP request and enforces security policies on the messages. Additionally, in this mode, OSB can add new security headers (including new authentication tokens) to the request that is forwarded on to the service. I’ll leave further discussion for other posts.

In pass-through mode, OSB leaves the SOAP message untouched and simply routes the request on to its destination service. This means that all security headers in the original request are preserved in the request sent on to the destination service. So if a SAML assertion is sent in the original request through OSB, it will be part of the request being sent on to the service.

Pass-through mode is great when OSB is being inserted into a working infrastructure (maybe for the purpose of SLA management) where the web services already have security in place and no identity transformation is required as requests move from the clients through OSB and on to the services themselves.

OOW Initial Impressions

Since I had to get up a 4 am to make my 6 am flight out to OOW, I am a little tired, but I had a few minutes back at the hotel before going out to dinner with IDM PM team, so just wanted to muster a quick post.

I forget how BIG Oracle is sometimes. OOW is a massive production, like an invasion of the Moscone center. It took me many minutes inside of the Oracle Demo grounds to find FMW, then IDM, then the people I was looking for to prep for my session tomorrow.

Once inside, some good discussions about a few use cases. I'll put this one out to the blog - in the OES, OWSM integration "Where should the policies for authorization, and specifically the policy defining the XPath of the attributes OES needs for authorization be managed?" For the presentation, I have them in OES policy, but I think there is a reasonable argument for them being defined inside of the OWSM policy. My thinking is that the encryption and signing policy (i.e. what parts of the body should be signed) are managed there...why not something like "Authorization XPath". Its obviously not as flexible....OES can determine on a per use or per role basis which attributes are required, but sometimes simpler is better, and maybe just having XPath defined in OWSM makes more sense. I'm on the fence...push me over.

Lunch with the boss, who even though I've worked for him for many years, I rarely get to see him face-to-face. Sushi across the street from Moscone is always good.

Also, at Hasan Rizvi's keynote, he made mention of a "standards based security platform for all of FMW" which is code for OPSS....solid mention.

Vikas and I finally huddled up and reviewed the demo/presentation for tomorrow. I'm excited, I think it all has come together quite nicely. Hopefully, I'll see some of you there tomorrow afternoon.