Overview
In order to function as an Application Server in an IMS network, 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) (http://www.3gpp.org/ftp/Specs/html-info/33222.htm).
            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 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 Oracle Fusion Middleware Securing Oracle WebLogic
                Server for more information.