1. Configuration Guide
  2. SIP Signaling Services
  3. Surrogate Agents and the Oracle Communications Session Border Controller
  4. Surrogate Agent Authentication Across Realms

Surrogate Agent Authentication Across Realms

The SBC uses an authentication attribute element in realms to support surrogate agent authentication requests initiated from other realms. This is a multi-instance element that supports the authentication of non-REGISTER traffic to surrogate agents with different authentication detail. The key for these lookups is the combination of the authentication realm and the authentication user lookup configurations. If you do not configure authentication attribute element in the realm, the SBC handles surrogate agent authentication using the authentication table setup on the IP-PBX session agent, which supports this traffic in a single realm only.

This feature resolves two key surrogate agent authentication issues:

  • In a multi-tenanted environment, there might be multiple IP-PBX systems or realms trying to use the same surrogate agent function. Therefore, there is a need to authenticate traffic to surrogate agents by the SBC on the SIP Trunk Realm with no association or relation to the IP-PBX system or realm.
  • In addition, some SIP Trunk providers send 401/407 challenges to all outbound calls. The SBC utilizes the authentication table setup on the session-agent for username/password to response to the 401/407 challenge. However, if the auth-realm value is the same for all customers, then the SBC cannot provide the correct username/password in response to the 401/407 challenge. When this feature is not set up, the SBC always uses the first entry on the auth-attributes in the session agent's table for all outbound calls.

You configure the SBC to populate the authentication headers using your configuration from either the softswitch's surrogate agent or realm during a 401/407 authentication challenge. The SBC uses these tables to look up the authentication realm and obtain the username and password. The SBC uses the username and password to authenticate the request.

Note:

The device initiating the authentication challenge to the surrogate agent does not need to be a softswitch.

The SBC chooses the table based on your configuration:

  • If you have configured the auth-user-lookup parameter in the local-policy attribute, then the SBC builds the authentication headers from the realm-config configuration.
  • If the auth-user-lookup parameter in the local-policy attribute is empty, then the SBC builds the authentication headers from the IP-PBX session-agent configuration.
The SBC uses the following objects to perform this feature's function:
  • A local-policy that forwards traffic to the target softswitch, which may or may not reside in a different realm from the source traffic. Further configuration supports intra-realm surrogate agent authentication.
  • The policy-attributes within that local-policy that includes the target auth-user-lookup value and the target realm of the surrogate agent.
  • An auth-attributes sub-element in the target realm-config. This sub-element includes:
    • The realm of the surrogate agent. This is the host realm initiating the authentication challenge. This value defines the protected space in which the digest authentication is performed.
    • An auth-user-lookup value that matches the auth-user-lookup in the local-policy.
    • The username and password that provide access to the target surrogate agent.