By Ken Fiedler and Nathan Ritter [Dec-07]

Figure 1

As part of uplifting Oracle's support systems technology we identified a business need to create a simplified portal interface for customers and employees separate from the analysts. We chose to use the latest Service Oriented Architecture (SOA) and fusion middleware for this project due to its ability to control access to sensitive company and customer data that resides across may dispersed systems.

In this blog we will describe the steps needed to secure Siebel web services using Oracle Web Service Manager (OWSM) and Oracle's Single Sign-On and LDAP server to control an ADF application's access to Siebel web services.

We will be implementing the scenario illustrated in Figure 1 above. The entire user authentication is via Oracle's SSO server and is controlled by responsibilities stored in Oracle's Internet Directory (OID)/LDAP server. OWSM will use the responsibilities stored in the OID's access control list (ACL) for the application to determine if the user is authorized to run the web service provided by Siebel's EAI/Custom Application Object Manager.

In follow on entries to this blog we will be describing the LDAP structures and accounts used to store the responsibilities. We will also describe setting up the Siebel trust token to handle the application authentication of the access manager login sessions and discuss the authentication of the user of web services against LDAP using the security adaptor. Following that, the required SOAP header structure and the configuration of the OWSM gateway policy to authorize against the LDAP structures will also be discussed. And finally, we will show some examples of calling Siebel web services from ADF using this security model.

By Ken Fiedler and Nathan Ritter [Mar-08]

Continuing on from the previous blog entry, this blog entry we will describe and provide examples of how to setup Oracle Internet Directory (OID) structures for Oracle Web Services Manager (OWSM) LDAP Authorization of Siebel Web services, which will be described in more detail in our next blog entry. (See Figure 1, red focus area).

In order to utilize OWSM LDAP Authorization policies, we must first define structures in the OID to store them. OID responsibilities should be created within the OracleContext object (cn=OracleContext, dc=oracle, dc=com). The steps below describe the process for creating the structures shown in Figure 2 and the required LDAP accounts needed by OWSM and Siebel.

Create the ADF Customer responsibility in the Domain:

This responsibilitiy will be used to allow authorized users run the Siebel web services.

Use ldapadd to run the following ldif file:

 dn: cn=ADF Customer,cn=OracleDefaultDomain,cn=OracleDBSecurity,cn=Products,cn=OracleContext,dc=oracle,dc=com
                    description: ADF Customer<
                    displayname: ADF Customer
                    cn: ADF Customer
                    orclisvisible: true
                    objectclass: top
                    objectclass: orclDBEnterpriseRole
                    objectclass: orclDBEnterpriseRole_82
                    objectclass: orclDBEnterpriseRole_10i
                    objectclass: groupofuniquenames
                    objectclass: orclprivilegegroup
                    objectclass: orclgroup

ADD a user (john_user) to the ADF Customer responsibility to grant him access to run the Siebel Web services.

 dn: cn=ADF Customer,cn=OracleDefaultDomain,cn=OracleDBSecurity,cn=Products,cn=OracleContext,dc=oracle,dc=com
                    changetype: modify
                    add: uniquemember
                    uniquemember: cn=john_user,l=users,dc=oracle,dc=com

Create WSM Client account

This OID account is used by OWSM’s LDAP Authorization policy and the OC4J application to query user’s responsibilities.
Use ldapadd to run the following ldif file.

dn: orclApplicationCommonName=WSMClient,cn=JAZNContext,cn=Products,cn=OracleContext
                    orclapplicationcommonname: WSMClient
                    objectclass: orclApplicationEntity
                    objectclass: top
                    userpassword: <password>

Add Application Accounts to the JAZN Administration Group

This is required to allow the OC4J application server security to query user’s responsibilities.
Use ldapmodify to run the following ldif

dn: cn=JAZNAdminGroup,cn=Groups,cn=JAZNContext,cn=Products,cn=OracleContext
                    changetype: modify
                    add: uniquemember
                    uniquemember: orclApplicationCommonName=WSMClient,cn=JAZNContext,cn=Products,cn=OracleContext 

Update the ACL for the Responsibility Domain

Grant the WSMClient user the ability to read the ACL.
Use ldapmodify with the following ldif.

dn: cn=OracleDefaultDomain,cn=OracleDBSecurity,cn=Products,cn=OracleContext,dc= 
                    oracle,dc=com
                    changetype: modify
                    add: orclaci
                    orclaci: access to attr=(uniquemember) filter=(objectClass=orclDBEnterpriseRole* 
                    ) by dn="orclApplicationCommonName=WSMClient,cn=JAZNContext,cn=Products,cn=OracleContext" 
                    (read,search,compare)

In future blogs, we will describe how to utilize these stuctures within OWSM and the ADF application in conjunction with Siebel trust tokens, to secure Siebel web services.