4 Configuring Security and Login Modules

This chapter describes how to set the security provider for an application. This chapter includes the following topics:

"Overview of Security"
"Configuring Subscriber Data Services"
"Configuring Applications to Use Login Modules"
"Security in SIP Servlets"
"Authentication Using the P-Asserted Identity Header"
"Authentication of Web Service Calls and XCAP Traffic"
"Configuring Oracle Internet Directory as the User Repository"

Overview of Security

OCMS implements both basic (HTTP) authentication and digest authentication as described in RFCs 3261 and 2617. In OCMS, both SIP and HTTP applications can be configured to authenticate against a RADIUS authentication system or Oracle Internet Directory (OID) version 10.1.4.0.1.

The application provides the infrastructure for authentication and authorization. This application, which is parent to applications requiring authentication, enables its child applications to access the authentication backend (RADIUS or Oracle Internet Directory) by means of native Enterprise JavaBeans (EJBs). Subscriber Data Services provides a framework that enables security but does not impose security constraints itself; this is done instead by its child applications, such as , which have authority constraints defined by the <security-constraint> element in sip.xml. For more information on configuring security in the deployment descriptor file, see "Security in SIP Servlets".

Each of the child applications of Subscriber Data Services must be configured to use a JAAS (Java Authentication and Authorization Service) login module for authentication and authorization against the configured user repository.

The OCMS JAAS-Compliant Login Modules

OCMS leverages the pluggable architecture of JAAS by providing the RADIUS Login Module that checks user credentials stored in the RADIUS user repositories for SIP or HTTP applications.

The RADIUS Login Module provides digest authentication for SIP applications as described in RFC 4590 and basic authentication HTTP applications for users provisioned to a RADIUS database.

The RADIUS database only authenticates users; it does not authorize users. Therefore, if you use the RADIUS Login Module, you must create users and assign the appropriate roles in the Oracle database that correspond to each user provisioned to the RADIUS database for role-based authorization. When deleting a user's authentication information from a RADIUS database, you must also delete that user's authorization information (for example, an account and role-related information) manually from the Oracle database. This prevents a future user provisioned with the same user name in RADIUS from inheriting the authorization and account-specific information of a user who had previously been deleted.

Note:

Due to licensing restrictions, open source RADIUS is not packaged with OCMS during installation. Prior to configuring the RADIUS Login Module with OCMS, the JRadius client library must be manually downloaded and installed. The necessary JRadius client library can be downloaded from the Sourceforge project at:

http://jradius-client.sourceforge.net/

Once the JRadius client library has been downloaded, manually copy the jradius-client.jar file to $ORACLE_HOME/j2ee/home/lib/ext on Oracle Containers for J2EE (OC4J) deploymentsYou must then restart the application server to deploy the RADIUS Login Module.

These pluggable JAAS login modules enable the SIP servlet container to perform authentication and authorization against external databases for User Agents sending SIP requests. The modules implement user authentication against the RADIUS user repositories by first invoking the JAAS LoginModule class and then by authorizing a previously authenticated user by verifying that the appropriate access permissions have been granted.

Note:

Because these login modules authenticate users against external repositories, they are considered custom security providers in OC4J. See Oracle Containers for J2EE Security Guide for information on configuring a custom security provider within a J2EE application.

Application Type and Authentication Mode

The type of authentication depends on the protocol used by the login module. As noted in Table 4-1, Digest authentication is used on the SIP side and Basic authentication is used on the HTTP side.

Note:

Although the Aggregation Proxy is a Web application, it is not limited to basic authentication because it explicitly performs authentication using internal security APIs. As a result, the Aggregation Proxy's default security settings (which set the authentication method as digest) will work without further configuration.

Table 4-1 Authentication Based on Protocol

Protocol	Authentication Mode
SIP	Digest
HTTP	Basic

Note:

This chapter describes how to specify the login module used by an application and how to configure the OCMS and RADIUS login modules themselves. See "Configuring Oracle Internet Directory as the User Repository" for information on using Oracle Internet Directory (OID), the LDAP data store used by Oracle WebCenter Suite, as the user provisioning repository for an OCMS deployment.

Configuring Subscriber Data Services

Subscriber Data Services (subscriberdataservices) is the parent application to all SIP applications that require authentication and security against the OCMS user repository. For example, the Application Router, Aggregation Proxy, and Proxy Registrar require Subscriber Data Services. In the case of the latter, the Location Service and the registrar component of the Proxy Registrar are dependent upon Subscriber Data Services. Subscriber Data Services also provides access to Oracle Internet Directory (OID). For more information, see "Overview of Security". See also "Configuring Oracle Internet Directory as the User Repository" for information on using Oracle Internet Directory (OID) as the user provisioning repository for an OCMS deployment.

Account Security

Subscriber Data Services provides account security through the Account Lockout Service and Login Failure service MBean groups.

The Account Lockout group includes the following MBeans:

AA Service

The AA Service MBean is used by the Login Failure Service to lock accounts. This MBean depends on the MathFunction Model MBeans, which enable the AA Service MBean to calculate the next lock duration for an account based on the current number of failed login attempts.

Note:

Account locking persists when you restart OC4J.

Table 4-2 describes the attributes of the AA Service MBean.

Table 4-2 Attributes of the AA Service MBean

Attribute	Value
MathFunction	The type of math function used to calculate the next lock duration for an account based on the number of current failed login attempts. The math functions, which include `Linear`, `Exponential` and `Constant`, are packaged as ModelMBeans. The default value is hotisp.math:service=MathFunction,name=Linear.
DefaultLockDuration	The lock duration, in seconds, to use if no math functions are available. The default value is 600.
JNDIName	The JNDI Name of the AA Service. This value is read-only
SecurityServiceName	The JNDI Name bound to the service object that is used to unlock user accounts. This value is read-only.

Table 4-3 Subscriber Data Services MBeans

MBean	Tasks
ModelMBeanDeployer	The helper MBean used by the Subscriber Data Services application to deploy its Model MBeans.

Constant (read-only)

The constant function used by the MathFunction MBean to calculate the next lock duration for an account based on the number of current failed login attempts.
Exponential

The exponential math function used by the MathFunction MBean to calculate the next lock duration for an account based on the number of current failed login attempts.
Linear

The linear math function used by the MathFunction MBean to calculate the next lock duration for an account based on the number of current failed login attempts.

Of the Subscriber Data Services MBeans, only AA Service and Command Service can be configured.

CommandService

The operations of the CommandService MBean enable you to execute the equivalent of Sash commands which are used to provision OCMS users to the Oracle database. For example, to view a list of commands for account management:

Click the Operations tab. A list of get commands appears.
Click help for a returning a help String for a partial command. The parameters for the help operation appear.
Enter account in the Value field.

Tip:
Click Use Multiline Editor to expand the Value field to accommodate long command names.
Click Invoke Operation. The commands pertaining to account management appear (Figure 4-1). These commands match those retrieved by entering help account at the Sash prompt. For more information, see "Viewing Subcommands" in Chapter 11, "Provisioning Users with Sash".

Figure 4-1 Viewing Help for a Command

Description of "Figure 4-1 Viewing Help for a Command"

To view a list of all of the available commands (Figure 4-2), select listAllCommands from the Operations tab and then click Invoke Operation from the listAllCommands page that appears. For a description of Sash commands, see "Viewing Available Commands". For more information on user management through Sash, see "Creating a User".

Figure 4-2 Viewing Available Commands

Description of "Figure 4-2 Viewing Available Commands"

The Command Service MBean is deployed within the presence application to enable user provisioning to the XDMS (XML Document Management Server). See Command Service (XDMS Provisioning).

Configuring Applications to Use Login Modules

You configure security for SIP applications by first defining the <security-constraint> element in the deployment descriptor file, sip.xml, setting the security provider (login module) appropriate to the authenticating user repository used by the application and then by configuring the login module itself. For more information on setting security in sip.xml, see "Security in SIP Servlets".

You can configure a login module for each application that you deploy. During the deployment process, you can configure the login module for SIP or HTTP applications using the Security Provider task in the Deployment Settings page of the Application Server Control deployment wizard. Once you deploy an application, you can examine or edit its login module's configuration From the Edit Login Module page, accessed from the Security Providers task in the Administration page (Figure 4-3).

Figure 4-3 Modifying a Login Module.

Description of "Figure 4-3 Modifying a Login Module."

For more information, see Deploying with Application Server Control Console in Oracle Containers for J2EE Deployment Guide

Configuring Login Modules though system-jazn-data.xml and orion-application.xml

Alternatively, login modules can also be configured through the <jazn-loginconfig> settings either in the system-jazn-data.xml file or in the orion-application.xml file located in an application's EAR (Enterprise Archive) file.

Configuring Login Modules in system-jazn-data.xml

The system-jazn-data.xml file is the repository for login module configuration. The settings in this file are updated when you administer login modules through Oracle Application Server Control (Figure 4-3) or through the OracleAS JAAS Provider Admintool. For more information, see Oracle Containers for J2EE Security Guide.

Table 4-4 describes the options supported by the OCMS Login Module and the RADIUS Login Module that you configure in system-jazn-data.xml.

Table 4-4 Login Module Options

Option	Description
`useUTF8`	If set to `true`, then the login module supports user names and passwords encoded in the UTF-8 character set.
`authMethod`	For SIP applications, select either `Basic` or `Digest`. For HTTP applications, select `Basic`.
`failurePeriod`	The time, in seconds, that an account is locked. The value entered in `orion-application.xml` takes precedence over the value entered in the `DefaultLockDuration` attribute of the AA Service MBean. See also .
`maxfailure`	The number of failed login attempts before an account is blocked.

Declaring the OCMS Login Module in orion-application.xml

The <jazn-loginconfig> element in orion-application.xml defines the login modules used by an application. The configurations you set in this file are populated to system-jazn-data.xml. Example 4-1 illustrate configuring login modules for authentication against a RADIUS authentication system.

Declaring the RADIUS Login Module in orion-application.xml

Example 4-1 defines a login module for the Proxy Registrar application. This application, however, requires users to be authenticated against the RADIUS database. In addition to the options described in Table 4-4, the RADIUS Login Module also supports the options described in Table 4-5.

Table 4-5 RADIUS Login Module Options

Option	Description
`hostname`	The host name or IP address of the remote RADIUS server.
`authPort`	The destination port for authentication requests.
`acctPort`	The destination port for the accounting server.
`sharedSecre`t	A `String` known only to the RADIUS server and the RADIUS client.

Example 4-1 Declaring the Radius Login Module in orion-application.xml

<jazn-loginconfig>
       <application Key="name">
           <name>proxyregistrar</name>
           <login-modules>
               <login-module Key="class control-flag">
                   <class>
                       oracle.sdp.radiusloginmodule.RadiusLoginModule
                   </class>
                   <control-flag>required</control-flag>
                   <options>
                       <option>
                           <name>useUTF8</name>
                           <value>true</value>
                       </option>
                       <option>
                           <name>authMethod</name>
                           <value>Digest</value>
                       </option>
                       <option>
                           <name>failurePeriod</name>
                           <value>600</value>
                       </option>
                       <option>
                           <name>maxFailure</name>
                           <value>5</value>
                       </option>
                       <option>
                           <name>hostName</name>
                           <value>127.0.0.1</value>
                       </option>
                       <option>
                           <name>authPort</name>
                           <value>1812</value>
                       </option>
                       <option>
                           <name>acctPort</name>
                           <value>1813</value>
                       </option>
                       <option>
                           <name>sharedSecret</name>
                           <value>secret</value>
                       </option>
                       <option>
                           <name>radiusClientClass</name>
                           <value>oracle.sdp.radiusloginmodule.JRadiusClient</value>
                       </option>
                   </options>
               </login-module>
           </login-modules>
       </application>
   </jazn-loginconfig>

Security in SIP Servlets

OCMS supports declarative and programmatic security for SIP servlets as described in the SIP Servlet API.

Declarative Security

The SIP Servlet API describes declarative security as expressing an application's security structure that includes roles, access control, and authentication requirements in a form that is external to the application^Foot 1. The deployment descriptor, sip.xml, is the vehicle for declarative security. Developers define how security should be effected in a deployed application by defining the <security-constraint> element. This element, which is described in detail in Oracle Communication and Mobility Server Developer's Guide, includes the following child elements (described in Table 4-6).

In OCMS, you first configure security for SIP applications by defining these elements. You can also set the login module used by the application in the system-jazn-data.xml file or in the orion-application.xml file as described in "Configuring Applications to Use Login Modules".

Note:

You can prevent a SIP application from performing authentication by removing the constraints defined in sip.xml and then by redeploying the application.

Table 4-6 Child Elements of the <security-constraint> Element

Element	Description
`<proxy-authentication>`	If this element is present in `SIP.xml`, the container must challenge the user agent with a 407 (Proxy Authentication Required) response status code when authenticating an incoming request or return a 401 response (Unauthorized).
`<resource-collection>`	A set of servlets and SIP methods. This element describes the servlet that requires authentication and the SIP methods used for authentication.
`<auth-constraint>`	Indicates the user roles that are permitted access to this resource collection.
`<role-name>`	The name of a security role.

Programmatic Security

Programmatic security describes the security model from inside a servlet using the SipServletMessage methods getRemoteUser, isUserInRole, and getUserPrincipal.

Authentication Using the P-Asserted Identity Header

The SIP Servlet API 1.0 states that in addition to basic and digest authentication, a User Agent authenticates users through the P-Asserted Identity, a SIP header field that conveys the identity of an authenticated user between the nodes of a trusted domain. As described in RFC 3325, a proxy within a trusted domain can receive messages from both trusted and non-trusted nodes alike. In the case of the latter, the proxy authenticates the originator of the message using digest authentication. The proxy then creates the P-Identity Asserted header field from the identity that it derived from authentication and places this field into the message header which it passes to other entities. For example, an inbound proxy server authenticates a user and then inserts the P-Asserted Identity header field into the received SIP message. By inserting the P-Asserted Identity header field, other servers within the trusted domain (such as the Presence Server) do not have to perform authentication again.

OCMS supports the trusted domain identity assertion described in RFC 3325 through the SipservletCommandInterceptors attribute of its Mbean.

Authentication of Web Service Calls and XCAP Traffic

OCMS supports Presence in Oracle Web Center 11g by allowing the Web Center system to manage their community memberships and presence authorization via APIs provided by OCMS. Web Center uses a community proxy user to represent a community to gain access to community members' presence information.

Web Services calls are authenticated by WS-Security. WS-Security is enabled by default to authenticate Web Service applications.

Default Role for All Users

OCMS 10.1.3.4 enables you to define a default role for all users in the JAAS (Java Authentication and Authorization Service) login modules. For example, you can define the role, PUBLIC, for all users by defining an <option> element in the system-jazn-data.xml file or in the orion-application.xml file located in an application's EAR (Enterprise Archive) file as illustrated in Example 4-2:

Example 4-2 Defining a Default Role for All Users

<option>
   <name>defaultRole</name>
   <value>{{PUBLIC}}</value>
</option>

Alternatively, you can configure security for SIP applications by first defining the <auth-constraint> subelement of <security-constraint> in the deployment descriptor file, sip.xml, and then by setting the security provider (login module) appropriate to the authenticating user repository used by the application and then by configuring the login module itself through the MBean browser.

Configuring Oracle Internet Directory as the User Repository

This section describes how to configure Oracle Internet Directory (OID), as the user provisioning repository for an OCMS deployment. This appendix includes the following sections:

"Overview of Configuration for OID Support"
"Configuring the OID LDAP Backend"
"Repackaging Subscriber Data Services"
"Provisioning OCMS Users to OID"

Overview of Configuration for OID Support

For OCMS to support authentication and authorization services for users provisioned to OID requires the following configuration for both OCMS and OID:

"Configuring the OID LDAP Backend"
"Installing OCMS Components into the OID LDAP Tree"
"Repackaging Subscriber Data Services"
"Provisioning OCMS Users to OID"

Prerequisites for OID Support

Using the OID data store requires the following:

A properly installed and configured instance of OCMS.
An instance of OID, Version 10.1.4.0.1.
For dynamic verifiers you must enable reversible password encryption for the LDAP realms employed for user authentication by selecting Userpassword Reversible Encryption. This configuration is not required for static verifiers.For more information, see Oracle Internet Directory Administrator's Guide.

Note:

OID is only supported for standalone OCMS deployments and OCMS deployments on Version 10.1.3.2 or higher of Oracle Application Server. See Oracle Communication and Mobility Server Installation Guide for further hardware and software requirements and installation options.

Configuring the OID LDAP Backend

You must also configure the following OID LDAP attributes for the OID LDAP backend:

orclcommonnicknameattribute (See "Mapping JAAS Usernames to LDAP User Entries".)
orclsubscribernicknameattribute (See "Mapping JAAS Realms to LDAP Subscribers".)
orclcommonnamingattribute (See "Mapping JAAS Roles to LDAP Groups".)

Mapping JAAS Usernames to LDAP User Entries

JAAS (Java Authentication and Authorization Service) user names are mapped to LDAP Users based on value of the orclcommonnicknameattribute under the node cn=Common, cn=Products, cn=OracleContext for each of the provisioned LDAP realms. For example, setting this attribute to uid for a given realm implies that SIP or Web users authenticating against OID must provide their corresponding LDAP UID as their username during authentication.

Mapping JAAS Realms to LDAP Subscribers

JAAS realms are mapped to LDAP Realm entries based on the value given to orclsubscribernicknameattribute under the root cn=Common, cn=Products, cn=OracleContext node for an OID deployment. For example, setting the value of orclsubscribernicknameattribute to o for an OID deployment implies that SIP or Web users authenticating against OID must belong to the JAAS realm identified by the value of the o attribute. As a result, user sip.user@company.com is challenged under the realm, company. The mapping of SIP domains to JAAS realms is exposed through the SipServletContainer's DomainsAndRealms attribute. In this example, the SIP domain, company.com, is mapped to the JAAS realm, company. The JAAS realm, company, is then mapped to the LDAP Subscriber for whom the value for the attribute in orclsubscribernicknameattribute (that is, the o attribute) is set to company. See also .

Mapping JAAS Roles to LDAP Groups

Group membership determines the JAAS roles for a specific user. Mapping LDAP groups to JAAS roles is based on the value given to orclcommonnamingattribute under the node cn=Common, cn=Products, cn=OracleContext for each of the provisioned LDAP Realms. For example, if a user belongs to an LDAP group with the distinguished name of cn=Location Service, cn=groups, dc=example, dc=com and the orclcommonnamingattribute is set to cn, then that JAAS user is populated with the "Location Service" JAAS role.

Installing OCMS Components into the OID LDAP Tree

To allow the OCMS container to connect to an instance of OID, its product container must be installed into OID's LDAP tree under the node cn=Products,cn=OracleContext for the appropriate LDAP realm(s). Each instance of OCMS that will connect to a given instance of OID must add an application entry under the OCMS product container, granting it the appropriate privileges, as described in "Associating an OCMS Instance with OID". In addition, if static verifiers are required for an OID deployment, an OCMS verifier entry must also be added under the OCMS product container. Installation of static verifiers is described in "Installing the OCMS Static Verifiers".

To integrate an instance of OCMS into a deployment of OID, you must make entries and modifications to OID's LDAP tree under the appropriate LDAP realm(s) (the examples use sample realm under dc=example,dc=com).

These modifications can be made through a graphical tool such as oidadmin or through a command-line tool such as ldapmodify with the appropriate LDIF definitions. The following sections provide examples of the LDIF configuration data that could be used to install OCMS components into OID's LDAP tree.

Associating an OCMS Instance with OID

Perform the following steps to associate an OCMS instance with OID:

Add the OCMS product container entry under the cn=Products,cn=OracleContext node for the appropriate LDAP realm:
```
dn: cn=OCMS,cn=Products,cn=OracleContext,dc=example,dc=com
changetype: add
objectclass: orclContainer
```

Associate an instance of OCMS by adding an OCMS application entry under the OCMS product container created above.

dn: orclApplicationCommonName=OCMSInstance1,cn=OCMS,cn=Products,cn=OracleContext, dc=example,dc=com
changetype: add
objectclass: orclApplicationEntity
orclappfullname: OCMS Instance 1
userpassword: password1
description: OCMS Instance 1 of the OCMS SIP Container

Grant verifier services privileges to the OCMS application by adding the OCMS application object as a member of the verifier services group.

dn:cn=verifierServices,cn=Groups,cn=OracleContext,dc=example,dc=com
changetype: modify Grant verifier services privileges to the OCMS application by adding the OCMS application object as a member of the verifier services group.
add: uniquemember
uniquemember: orclApplicationCommonName=OCMSInstance1, cn=OCMS,cn=Products,cn=OracleContext,dc=example,dc=com

Repeat steps 2 and 3 for each instance of OCMS wishing to associate with this OID LDAP server for its user data store.

Installing the OCMS Static Verifiers

Perform the following step to install OCMS static verifiers:

Add the OCMS verifier entry under the OCMS product container. This step is not required for deployments of OID configured to use dynamic verifiers.
```
dn: cn=OCMSVerifierProfileEntry,cn=OCMS,cn=Products,cn=OracleContext, dc=example,dc=com
objectclass:top
objectclass:orclpwdverifierprofile
cn:OCMSVerifierProfileEntry
orclappid:ocms
orclpwdverifierparams;authpassword: crypto:SASL/MD5 $ realm:example $ usernameattribute:mail $usernamecase:lower
```
Set the usernameattribute above to the value of the orclcommonnicknameattribute under the node cn=Common,cn=Products,cn=OracleContext for the given LDAP realm where the verifier is to be installed.

Set the realm verifier parameter to match one of the JAAS realms configured in the SipServletContainer's DomainsAndRealms JMX attribute, as described in "Mapping JAAS Realms to LDAP Subscribers".

Set the orclappid attribute to a unique component name assigned to the OCMS component. The value of this attribute determines the value of the StaticVerifierAttribute used for the Security Service EJB configuration in "Configuring User Service and Security Service". For example, if orclappid is set to "ocms", then the StaticVerifierAttribute should be set to "authpassword;ocms", following the general static verifier pattern of authpassword;orclappid (where authpassword is a static string).

Refer to Oracle Internet Directory Administrator's Guide 10g for more information on static verifiers.

Repackaging Subscriber Data Services

Configuring OCMS to support OID requires that Subscriber Data Services (subscriberdataservices.ear) and its child applications be undeployed from the OCMS OC4J instance. Before the application and its child applications can be re-deployed, the user service and security service EJB configuration must be altered by adding the following LDAP configuration parameters to the ejb-jar.xml files for securityservice.jar and userservice.jar:

java.naming.security.principal
java.naming.provider.url
java.naming.security.protocol (an optional parameter)

The user service EJB configuration also exposes the SipUriLdapAttribute, which defines the LDAP user attribute where the SIP URI is stored. This attribute defaults to mail if no value is defined.

Configuring User Service and Security Service

To configure the Subscriber Data Services application with OID as the user provisioning store:

Copy the EAR file of the Subscriber Data Services application (subscriberdataservices.ear) as well as its child applications to a temporary directory.
Undeploy the Subscriber Data Services application and its child applications from the OC4J instance. See .
Expand the Subscriber Data Services application in the temporary directory.
Expand securityservice.jar

Edit ejb-jar.xml (located under META-INF) by replacing the following entry with the entry listed in Example 4-3 that includes the java.naming.security.principal, java.naming.provider.url, and the java.naming.security.protocol parameters.

<env-entry>
            <description><![CDATA[Datasource for Service activation  facades]]></description>
            <env-entry-name>SecurityServiceDSN</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[java:jdbc/OcmsSsDs]]></env-entry-value>
         </env-entry>
         <env-entry>
            <env-entry-name>SecurityDAOImpl</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
             <env-entry-value><![CDATA[com.hotsip.securityservice.dao.timesten.SecurityDAOImpl]]>
            </env-entry-value>
         </env-entry>
         <env-entry>
            <env-entry-name>StoreHashedCredentials</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[True]]></env-entry-value>
         </env-entry>
         <env-entry>
            <description><![CDATA[Datasource for Service activation facades]]></description>
            <env-entry-name>UserServiceDSN</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[java:jdbc/OcmsUsDs]]></env-entry-value>
         </env-entry>
         <env-entry>
            <env-entry-name>UserDAOImpl</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[oracle.sdp.userservice.dao.timesten.UserDAOImpl]]>
            </env-entry-value>
         </env-entry>

Example 4-3 ejb-jar.xml Entries

<env-entry>
            <description><![CDATA[DN of the OCMS LDAP application entry for this instance of OCMS.]]></description>
            <env-entry-name>java.naming.security.principal</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[orclApplicationCommonName=OCMSInstance1,cn=OCMS,cn=Products,cn=OracleContext, dc=example,dc=com]]></env-entry-value>
         </env-entry>
         <env-entry>
            <description><![CDATA[Password for the OCMS LDAP application entry for this instance of OCMS.]]></description>
            <env-entry-name>java.naming.security.credentials</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[{903}FOO48C7YXgS6EMBZ4I47/Xs0JsjJXuHOUlVCyJzWHXo=]]></env-entry-value>
         </env-entry>
         <env-entry>
            <description><![CDATA[LDAP Provider URL]]></description>
            <env-entry-name>java.naming.provider.url</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[ldap://ldapusers.example.com:636]]></env-entry-value>
         </env-entry>     
         <env-entry>
            <description><![CDATA[Security Protocol (e.g. ssl)]]></description>
            <env-entry-name>java.naming.security.protocol</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[ssl]]></env-entry-value>
         </env-entry>              
         <env-entry>
            <description><![CDATA[The LDAP user attribute containing the user's static verifier hash.]]></description>
            <env-entry-name>StaticVerifierAttribute</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[authpassword;ocms]]>
            </env-entry-value>
         </env-entry> 
         <env-entry>
           <description><![CDATA[The optional LDAP filter that should be applied when searching for users.]]></description>
           <env-entry-name>UserSearchFilter</env-entry-name>
           <env-entry-type>java.lang.String</env-entry-type>
           <env-entry-value><![CDATA[(&(mail=*@example.com)(orclisvisible=true))]]>
           </env-entry-value>
         </env-entry>
         <env-entry>
            <env-entry-name>SecurityDAOImpl</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[oracle.sdp.securityservice.dao.ldap.SecurityDAOImpl]]>
            </env-entry-value>
         </env-entry>
         <env-entry>
            <env-entry-name>UserDAOImpl</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value><![CDATA[oracle.sdp.userservice.dao.ldap.UserDAOImpl]]>
            </env-entry-value>
         </env-entry>

Note:

The java.naming.security.principal, java.naming.security.credentials and java.naming.provider.url environment entries must be updated with the LDAP server's configuration. Typically, the entry for java.naming.security.principal will be set to the dn for the orclApplicationEntity object associated with the current instance of OCMS. The optional entry, java.naming.security.protocol, must be set to "ssl" for SSL-based connections to the OID LDAP server.

The value of java.naming.security.credentials can be provided in cleartext by prepending the "!" character to the cleartext password (for example, "!password"). For additional security, use the obfuscated form of the password.

In OID deployments configured to use dynamic verifiers, the StaticVerifierAttribute entry is not needed and should be removed. In OID deployments configured to use static verifiers, the StaticVerifierAttribute entry should be set to the user attribute where the OCMS static verifier is stored. Typically, the value of this attribute is "authpassword;orclappid", where authpassword is a static string and orclappid is replaced by the value of the orclappid attribute uniquely identifying the OCMS static verifier installed into OID. The optional UserSearchFilter attribute sets the value of the LDAP filter to apply when searching for users in the LDAP repository. If omitted, no user search filter will be applied.

Repackage securityservice.jar.
Expand the userservice.jar.

Edit the ejb-jar.xml under META-INF by replacing the following entry with the entry described in Example 4-4 that includes the java.naming.security.principal, java.naming.provider.url, java.naming.security.protocol, and SipUriLdapAttribute parameters. Do not remove the UserServiceDSN entry.

<env-entry>            <description><![CDATA[Datasource for Service activation facades]]></description>            ...            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[java:jdbc/OcmsUsDs]]></env-entry-value>         </env-entry>         <env-entry>            <env-entry-name>UserDAOImpl</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[oracle.sdp.userservice.dao.timesten.UserDAOImpl]]>            </env-entry-value>         </env-entry>

Example 4-4 userservice.jar Entries

<env-entry>            <description><![CDATA[DN of the OCMS LDAP application entry for this instance of OCMS.]]></description>            <env-entry-name>java.naming.security.principal</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[orclApplicationCommonName=OCMSInstance1,cn=OCMS,cn=Products,cn=OracleContext, dc=example,dc=com]]></env-entry-value>         </env-entry>         <env-entry>            <description><![CDATA[Password for the OCMS LDAP application entry for this instance of OCMS.]]></description>            <env-entry-name>java.naming.security.credentials</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[{903}FOO48C7YXgS6EMBZ4I47/Xs0JsjJXuHOUlVCyJzWHXo=]]></env-entry-value>         </env-entry>         <env-entry>            <description><![CDATA[LDAP Provider URL]]></description>            <env-entry-name>java.naming.provider.url</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[ldap://ldap.example.com:636]]></env-entry-value>         </env-entry>              <env-entry>            <description><![CDATA[The optional LDAP user attribute containing the user's SIP URI.]]></description>            <env-entry-name>SipUriLdapAttribute</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[mail]]></env-entry-value>         </env-entry>         <env-entry>           <description><![CDATA[The optional LDAP filter that should be applied when searching for users.]]></description>           <env-entry-name>UserSearchFilter</env-entry-name>           <env-entry-type>java.lang.String</env-entry-type>           <env-entry-value><![CDATA[(&(mail=*@example.com)(orclisvisible=true))]]>           </env-entry-value>         </env-entry>         <env-entry>            <description><![CDATA[Security Protocol (e.g. ssl)]]></description>            <env-entry-name>java.naming.security.protocol</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[ssl]]></env-entry-value>         </env-entry>                                            <env-entry>            <env-entry-name>UserDAOImpl</env-entry-name>            <env-entry-type>java.lang.String</env-entry-type>            <env-entry-value><![CDATA[oracle.sdp.userservice.dao.ldap.UserDAOImpl]]>            </env-entry-value>         </env-entry>

Note:

The java.naming.security.principal, java.naming.security.credentials and java.naming.provider.url environment entries must be updated with the LDAP server's configuration. In addition, the optional entry, java.naming.security.protocol, must be set to "ssl" for SSL-based connections to the OID LDAP server. The userservice exposes an optional environment parameter, SipUriLdapAttribute. The value set for this entry is the LDAP user attribute where the SIP URI is stored. If no value is set for this entry, then the attribute defaults to mail.

Repackage userservice.jar.
Repackage the EAR file for Subscriber Data Services.
Redeploy the repackaged Subscriber Data Services application and its child applications to the OCMS OC4J instance.

Provisioning OCMS Users to OID

You must provision user accounts to OID using the Oracle Identity Management (OIM) Web-based Oracle Delegated Administration Services application (OIDDAS), described in Oracle Identity Management Guide to Delegated Administration.

You access this tool from a browser by entering http://<host>:<port>/oiddas, where the host and port are the hostname and HTTP port for the Oracle Application Server instance of the OID deployment.

Adding Users to LDAP Groups

Proxy registrar can be configured to have users with any roles by assigning a default PUBLIC role.

Using Oracle Delegated Administration Services, you can add a user to an LDAP group by adding the distinguished name of the user to the list of values in the LDAP group's uniquemember attribute. For more information, refer to Oracle Identity Management Guide to Delegated Administration.

You can also configure the sip.xml authentication constraints in proxyregistrar to require user membership in a particular role (for example, Location Service), based on the SIP message type.

Footnote Legend

Footnote 1: SIP Servlet API, Version 1.0