ISG works with external devices, referred to as policy servers that store per-subscriber and per-service information. ISG supports two models of interaction between the ISG and external policy servers: initial authorization and dynamic authorization.

In the initial authorization model, ISG must retrieve policies from the external policy server at specific points in a session. In this model, the external policy server is typically an authentication, authorization, and accounting (AAA) server that uses RADIUS. ISG is the RADIUS client. Instead of a AAA server, some systems use a RADIUS proxy component that converts to other database protocols, such as Lightweight Directory Access Protocol (LDAP).

The dynamic authorization model allows the external policy server to dynamically send policies to ISG. These operations can be initiated in-band by subscribers (through service selection) or through the actions of an administrator, or applications can change policies on the basis of some algorithm (for example, change session quality of service (QoS) at a certain time of day). This model is facilitated by the Change of Authorization (CoA) RADIUS extension. CoA introduces peer-to-peer capability to RADIUS that enables ISG and the external policy server to act as the RADIUS client and server respectively.

Triple key authentication is a method of authenticating users based on their username, password, and location after ISG redirects them to the Cisco Service Management Engine (SME) portal. The SME server provides the location based on the source IP address of the subscriber being authenticated. Before the Triple Key Authentication Support feature was introduced, users were authenticated only on the basis of the username and password (two-key authentication). The Triple Key Authentication Support feature also eases migration from Service Selection Gateway (SSG) to an ISG platform because SSG uses triple key authentication.

For SSG, the Cisco Subscriber Edge Services Manager (SESM) server populates RADIUS attribute 31 (calling-station ID) in the user-login request that it sends to the SSG with a string containing the subscriber's location. The SSG then includes this location string in the access-request message that it sends to the RADIUS server where the login is authenticated based on the username, password, and location string.

With ISG triple key authentication, the ISG sends the location string within a Cisco vendor-specific attribute (VSA) that is included in the access-request message to the RADIUS server.

The location information is received from SME as Cisco VSA 250. This location information is included in session authentication requests, session accounting requests from the ISG, and prepaid authorization requests.

The table below shows the Cisco vendor-specific non-AVPair attribute used for triple key authentication.

1.    enable

2.    configure terminal

3.    aaa authentication login {default | list-name} method1 [method2...]

4.    aaa authentication ppp {default | list-name} method1 [method2...]

5.    aaa authorization {network | exec | commands level | reverse-access | configuration} {default | list-name} [method1 [method2...]]

6.    aaa authorization subscriber-service {default {cache | group | local} | list-name} method1 [method2...]

7.    aaa service-profile key username-with-nasport

8.    aaa accounting {auth-proxy | system | network | exec | connection | commands level} {default | list-name} [vrf vrf-name] {start-stop | stop-only | none} [broadcast] group group-name

9.    end

1.    enable

2.    configure terminal

3.    aaa server radius dynamic-author

4.    client {name | ip-address} [key [0 | 7] word] [vrf vrf-id]

5.    port port-number

6.    server-key [0 | 7] word

7.    auth-type {all | any | session-key}

8.    ignore {server-key | session-key}

9.    end

1.    enable

2.    configure terminal

3.    aaa new-model

4.    radius-server vsa send accounting

5.    radius-server vsa send authentication

6.    end