Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

SAE Plug-Ins

 

Plug-ins are software programs that extend the capabilities of existing programs and make them more flexible. SRC plug-ins provide authentication, authorization, and tracking capabilities.

There are three types of plug-ins: internal, hosted, and external. Internal plug-ins communicate directly with the SAE. Hosted and external plug-ins implement a published Common Object Request Broker Architecture (CORBA)-based service provider interface (SPI), which means that anyone with access to the interface specification can create plug-ins that work with the SRC module. Figure 1 gives an overview of the plug-in architecture.

Figure 1: SAE Plug-In Architecture
SAE Plug-In Architecture

Internal Plug-Ins

The SRC module provides internal plug-ins that perform a range of authentication, authorization, and tracking functions. With these plug-ins, you can, for example, authenticate subscribers, authorize subscriptions and sessions, authorize IP address requests from DHCP clients, track subscriber activity and service use, track quality of service (QoS) services and attach and remove QoS profiles as needed, and limit the number of authenticated subscribers who connect to an IP interface on the router.

Internal plug-ins implement an interface that communicates directly with the SAE. They have the following characteristics:

  • Run within the SAE’s Java Virtual Machine (JVM)

  • Are started and stopped with the SAE

  • Are implemented in Java

The core SRC module provides a set of internal plug-ins.

External Plug-Ins

The SRC module includes the SAE CORBA plug-in SPI. This SPI allows you to implement external plug-ins in any language that supports CORBA (for example, Java, C++, Python), which makes it easy to integrate the SAE with operations support system (OSS) software written in a wide variety of languages and distributed across a variety of hardware and operating system platforms.

External plug-ins link a service provider’s OSS with the SAE so that the OSS is notified of events in the life cycle of SAE sessions. For example, plug-ins can be notified when a subscriber attempts to log in and begins the authentication and authorization process. This notification makes it possible for the plug-in to consult general data and resource allocation information that is available to the OSS, and use that information to make authorization decisions.

The SPI also sends session-tracking events when sessions start, on an interim basis, and when sessions stop. Plug-ins can set session timeouts as a response to both session start and interim events. This capability enables the development of prepaid applications where the plug-in consults the subscriber’s current account balance before it makes the decision to extend or reduce a session timeout.

External plug-ins have the following characteristics:

  • Run outside the SAE’s JVM, either in the same or in a different server

  • Are implemented in any language that supports CORBA

  • Communicate with the SAE using CORBA

  • Support the admission control or prepaid demo plug-in, which can be purchased separately from the SRC module.

Hosted Plug-Ins

Hosted plug-ins, like the external ones, implement the CORBA interface. Unlike the external ones, hosted plug-ins are instantiated (that is, hosted) by the SAE. As a result, they live in the same JVM process as the host SAE, which means that hosted plug-ins must be implemented in Java.

Hosted plug-ins have the following characteristics:

  • Run within the SAE’s JVM

  • Communicate with SAE using CORBA

  • Are started and stopped with SAE

  • Are implemented using a published interface