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

Cross Realm Surrogate Agent Authentication Operation

After configuration, the SBC authenticates applicable cross-realm surrogate agent authentication, allowing registration and call traffic.

When the SBC receives traffic that triggers your local-policy, it uses the policy's auth-user-lookup value in combination with the target realm of the local-policy to prepare for authentication.

The key used for these lookups is a combination of the authentication realm and the user lookup. Typical behavior during operation includes:

  • If the auth-user-lookup in the policy-attribute is empty, the SBC gets the configured password for authorization from the softswitch session-agent configuration.
  • If the auth-user-lookup in the policy-attribute is not empty, the SBC selects the AuthAttributes (username/password) for the matching auth-user-lookup in the realm-config.
  • If the auth-user-lookup in policy-attribute is not empty, but there is no corresponding entry in realm-config, then the call fails as unauthorized. Additionally, the SBC displays a warning during verify-config.

When operating with the auth-user-lookup from the local-policy attributes, the SBC uses the returned value of username and password for authenticating the request. During the processing of the INVITE request, a reference to the selected local policy route is stored along with the route.

Additional Notes on Operation

The following are additional notes that describe the digest authentication process:

  • The SBC always challenges the first LOGIN request, and initial authentication begins with that request. The selected authorization key — the credentials — are then included in every subsequent request.
  • If the SBC does not receive any communication from the client within the expiration period, the SBC logs the client out and tears down the transport connection. Faced with interface loss, the SBC default behavior is to flush all warrant information from the target database. This response necessitates that the client first login/re-register with the SBC, and then repopulate the empty database using a series of ADD requests. This behavior ensures that client and SBC target databases are synchronized. 

Alternatively, when faced with interface loss, the SBC can retain all warrant information within the target database. This response necessitates only that the client first login/re-register with the SBC. After successful registration the client should, but is not required to, use a series of GET, ADD, and DELETE requests to ensure that the SBC and client target databases are synchronized.
  • The SBC ignores the Authentication-Info header that comes in the 200OK response after digest authentication is complete. The SBC receives a 401/407 response from the client. However, some surrogate-agents may process the Authentication-Info header in a single challenge.