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 Identity Assertion for SIP Servlets

The following sections describe how to configure and use Oracle Communications Converged Application Server Identity Asserter providers:

 

Overview of SIP Servlet Identity Assertion Mechanisms

A SIP Servlet can be configured to use one of the following identity assertion mechanisms:

The selected identity assertion mechanism is defined in the identity-assertion element of the sip.xml deployment descriptor. The identity-assertion-support element determines whether the identity assertion mechanism is required for the Servlet, or whether alternate authentication mechanisms can be used with SIP messages that do not contain the required headers. See the SIP Servlet Specification v1.1 for more information on configuring identity assertion for a Servlet.

Oracle Communications Converged Application Server supports identity assertion mechanisms using security providers. The sections that follow describe how Oracle Communications Converged Application Server handles messages with each identity assertion mechanism, and how to configure the required security providers.

Note: Oracle Communications Converged Application Server version provides backward compatibility for applications that conform to the SIP Servlet v1.0 specification. For all v1.0 SIP Servlets that contain a P-Asserted-Identity header, the container uses the identity assertion process described in Configuring P-Asserted-Identity Assertion in the SIP Server version 3.1 documentation.

 

Understanding Trusted Host Forwarding with P-Asserted-Identity

The P-Asserted-Identity header is honored only within a trusted domain. In a Oracle Communications Converged Application Server system, trusted domains are purely configuration-based. To enable use of the header, you must configure one of two available P-Asserted Identity Assertion providers as described in Configuring a P-Asserted-Identity Assertion Provider. The P-Asserted-Identity assertion providers expose the trusted domain configuration for P-Asserted-Identity headers. If you do not configure a provider, the header considers no IP addresses as being “trusted.”

When Oracle Communications Converged Application Server receives a message having the P-Asserted-Identity header from a trusted host configured with the provider, it logs in the user specified in the header to determine group membership and other privileges. The value contained in the P-Asserted-Identity header must be a SIP address (for example, sipuser@oracle.com). By default, Oracle Communications Converged Application Server removes the domain portion of the address (@oracle.com) and uses the remainder as the user name. If you must support overlapping usernames from different names (for example, sipuser@oracle.com and sipuser@cea.com), you can create and use a custom user-name mapper to 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.

The presence of a P-Asserted-Identity header combined with the Privacy header also determines the way in which Oracle Communications Converged Application Server proxies incoming requests. The value of the identity-assertion-support element in sip.xml is also considered. Figure 4-1 describes how incoming SIP requests are managed in relation to the P-Asserted-Identity header.

Figure 4-1 Managing Inbound Requests Having P-Asserted-Identity and Privacy Headers

Managing Inbound Requests Having P-Asserted-Identity and Privacy Headers

Figure 4-2 describes the standard security check procedure that Oracle Communications Converged Application Server uses when an asserted user name is not authorized to access a requested resource. The standard security check is performed according to the auth-method defined in the login-config element of the sip.xml descriptor for the current application.

Figure 4-2 Standard Security Check Procedure

Standard Security Check Procedure

The presence of a P-Asserted-Identity header or a P-Preferred-Identity header also affects the processing of outbound SIP requests. Figure 4-3 describes the behavior.

Figure 4-3 Managing Outbound Requests Having P-Asserted-Identity or P-Preferred Identity

Managing Outbound Requests Having P-Asserted-Identity or P-Preferred Identity

 

Overview of Strict and Non-Strict P-Asserted-Identity Asserter Providers

If the contents of a P-Asserted-Identity header are invalid, or if the header is received from a non-trusted host, then the security provider returns an “anonymous” user to the SIP Servlet container. If you configured the PAsserted Identity Strict Asserter provider, an exception is also thrown so that you can audit the substitution of the anonymous user. (If you configured the basic PAsserted Identity Asserter provider, no exception is thrown.)

With either provider, if identity assertion fails and the requested resource is protected (the request matches a security-constraint defined in sip.xml), the SIP container uses the auth-method defined in the sip.xml deployment descriptor to challenge the end user. For example, digest authentication may be used if the Servlet specifies the digest authentication method.

If the requested resource is not protected, the anonymous user is simply passed to the SIP Servlet without authorization. Because the 3GPP TS 24.229 specification recommends forced authorization even when a resource is unrestricted (and privacy is not requested), you should use declarative security to protect all of a SIP Servlet’s resources to remain compliant with the specification. See Securing SIP Servlet Resources in Developing SIP Applications for more information.

If authorization of the anonymous user fails, Oracle Communications Converged Application Server then forces authentication by challenging the user.

 

Configuring a P-Asserted-Identity Assertion Provider

Follow these steps to configure a security provider used to support the P-Asserted-Identity header. Note that one of two providers can be selected, as described in Overview of Strict and Non-Strict P-Asserted-Identity Asserter Providers.

In addition to configuring one of the above providers, configure a secondary, “fallback” login method (for example, using DIGEST or CLIENT-CERT authentication).

To configure a P-Asserted-Identity provider:

  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. Click New.
  5. Enter a name for the new provider, and select one of the following options for the Type:
    • PAssertedIdentityAsserter—Select this option to configure a provider that does not throw an exception when the P-Asserted-Identity header is invalid or is received from a non-trusted host and an anonymous user is substituted.
    • PAssertedIdentityStrictAsserter—Select this option to configure a provider that throws an exception when the P-Asserted-Identity header is invalid or is received from a non-trusted host and an anonymous user is substituted.

      • See Overview of Strict and Non-Strict P-Asserted-Identity Asserter Providers for more information.

  6. Click OK.
  7. Select the name of the provider you just created.
  8. Select the Configuration->Provider Specific tab.
  9. Fill in the fields of the configuration tab as follows:
    • Trusted Hosts: Enter one or more host names that the provider will treat as trusted hosts. You can enter a list of IP addresses or DNS names, and wildcards are supported.
      • Note: The provider does not use trusted hosts configured in the sipserver.xml file (see sip-security in the Configuration Reference Manual.)
    • User Name Mapper Class Name: Enter the name of a custom Java class used to map user names in the P-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 usernames received from each domain. A custom user name mapper class is required if you want to map usernames in the P-Asserted-Identity header to WebLogic usernames. 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 resulting user name without applying any additional logic.

  10. Click Save.

 

Understanding Identity Assertion with the Identity and Identity-Info Headers

Oracle Communications Converged Application Server can also perform identity assertion using the Identity and Identity-Info headers, as described in RFC 4474. As with the p-asserted-identity assertion mechanism, Identity header assertion requires that you first configure the appropriate security provider (the IdentityHeaderAsserter provider) in Oracle Communications Converged Application Server.

When asserting the identity of inbound requests having the Identity and Identity-Info headers, Oracle Communications Converged Application Server considers the values of the identity-assertion and identity-assertion-support elements in sip.xml as well as the presence of a configured security provider. Figure 4-4 describes how incoming messages are processed using this assertion mechanism.

Figure 4-4 Managing Inbound Requests Having Identity and Identity-Info Headers

Managing Inbound Requests Having Identity and Identity-Info Headers

 

Configuring the Identity Header Assertion Provider

Follow these steps to configure the security provider used to support the Identity header:

  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. Click the Providers->Authentication tab in the right pane.
  5. Click New.
  6. Enter a name for the new provider, and select IdentityHeaderAsserter for the Type.
  7. Click OK.
  8. Select the name of the provider you just created.
  9. Select the Provider Specific tab.
  10. Fill in the fields of the configuration tab as follows:
    • Date Period: Enter the valid period for Date header, in seconds.
    • Https Channel Name: Enter the name of an HTTPS channel the provider should use to initialize an HTTPS client. An HTTPS channel is required (and must be configured separately) if a remote certificate must be retrieved via HTTPS.
    • User Name Mapper Class Name (optional): Enter the name of a custom Java class used to map user names in the Identity header to user names in the default security realm. A custom user name mapper class is required if you want to map usernames in the Identity header to WebLogic usernames. See Configuring a Role Mapping Provider in the Oracle WebLogic Server 10g Release 3 Documentation for more information.
  11. Click Save.

  Back to Top       Previous  Next