Configuring Security

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring 3GPP HTTP Authentication Providers

The following sections describe how to configure Oracle Communications Converged Application Server to handle the X-3GPP-Asserted-Identity header for HTTP authentication:

 

Overview

In order to function as an Application Server in an IMS network, Oracle Communications Converged Application Server supports handling the X-3GPP-Asserted-Identity header as specified in 3GPP TS 33.222 Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS). Oracle Communications Converged Application Server provides this support via a configured security provider, X3gppAssertedIdentityAsserter or X3gppAssertedIdentityStrictAsserter. The providers use the same authentication process, but the “strict” assertion provider also throws an exception when the header is received from a non-trusted host (which enables you to audit asserted identity requests from non-trusted hosts).

The X-3GPP-Asserted-Identity header functions for HTTP requests in the same manner that the P-Asserted-Identity header functions for SIP requests. When the container receives an incoming HTTP requesting having a X-3GPP-Asserted-Identity header, it first verifies that the request was received from a trusted host. If the host was trusted, the container asserts the user’s identity using the information in the header, authenticates the user, and logs the user in if that user is authorized to access the requested resource. (If a request comes from a non-trusted host, the container simply ignores the header.)

The X-3GPP-Asserted-Identity header may contain multiple names in a list (for example, user1@oracle.com, user2@oracle.com). When configured with the default user name mapper class, the Oracle Communications Converged Application Server providers remove the domain portion of the addresses (@oracle.com) and use the remainder as the user name. The default user name mapper always chooses the first username in the list and uses it for asserting the identity. This behavior can be changed by creating and configuring a custom user name mapper class. For example, if you must support overlapping usernames from different names (for example, sipuser@oracle.com and sipuser@cea.com), a custom user-name mapper might process the header contents into a unique username (for example, sipsuser_b and sipuser_c). Using a custom user name mapper also enables you to support WebLogic user names that contain an “@” character, such as @oracle.com.

In order for SIP Servlets to support authentication with the X-3GPP-Asserted-Identity header, the auth-method element must be set to CLIENT-CERT in the web.xml deployment descriptor. See web.xml Deployment Descriptor Elements in the Oracle WebLogic Server 10g Release 3 Documentation for more information.

 

Configuring a X-3GPP-Asserted-Identity Provider

Follow these steps to configure a security provider used to support the X-3GPP-Asserted-Identity header in HTTP requests. Note that one of two providers can be selected, as described in the Overview:

  1. Log in to the Administration Console for the Oracle Communications Converged Application Server domain you want to configure.
  2. In the left pane of the Console, select the Security Realms node.
  3. Select the name of your security realm in the right pane of the Console. (for example, “myrealm”).
  4. Select the Providers->Authentication tab.
  5. Click New.
  6. Enter a name for the new provider, and select one of the following options for the Type field:
    • X3gppAssertedIdentityAsserter—Select this option to configure a provider that does not throw an exception when the header is invalid or is received from a non-trusted host.
    • X3gppAssertedIdentityStrictAsserter—Select this option to configure a provider that throws an exception when the header is received from a non-trusted host and is therefore ignored.

      • See Overview for more information.

  7. Click OK.
  8. Select the name of the new provider you just created.
  9. In the Active Types Chooser list, select the X-3GPP-Asserted-Identity type and use the arrow to move it to the Chosen column.
  10. Click Save.
  11. Select the Configuration->Provider Specific tab.
  12. Fill in the fields of the configuration page as follows:
    • Trusted Hosts: Enter one or more host names that the provider will treat as trusted hosts. Note that the provider does not use trusted hosts configured in the sipserver.xml file (see sip-security in the Configuration Reference Manual.) You can enter a list of IP addresses or DNS names, and wildcards are supported.
    • User Name Mapper Class Name: Enter the name of a custom Java class used to map user names in the X-3GPP-Asserted-Identity header to user names in the default security realm. A custom user name mapper is generally used if user names are received from two or more different domains. In this case additional logic may be required to map user names received from each domain. A custom user name mapper class is required if you want to map usernames to WebLogic usernames, or if you want to logically process multiple usernames specified in the X-3GPP-Asserted-Identity header (rather than using only the first username). See Configuring a Role Mapping Provider in the Oracle WebLogic Server 10g Release 3 Documentation for more information.

      • Alternately, leave this field blank to use the default user name mapper. The default mapper simply discards the domain name and takes the first resulting user name to assert the identity. For example, the default user name mapper takes the following header: 

      X-3GPP-Asserted-Identity: "user1@oracle.com", "user2@oracle.com"

      and asserts the identity “user1.”

  13. Click Save.

  Back to Top       Previous  Next