Introducing RADIUS
RADIUS is a lightweight, datagram-based protocol formally specified in RFC 2865 that is supported by many devices and servers for external authentication. VPN concentrators, routers, switches, wireless access points, and many other devices have native RADIUS support. Such devices are known as RADIUS clients. Using the RADIUS protocol, they converse with RADIUS servers to authenticate entities, such as users attempting to access their resources.
The RADIUS protocol itself is quite simple. There are four packet types:
Access-Requestpackets are sent from a client to a server to begin a new authentication conversation, or to respond to a previous response in an existing conversation and provide requested information.Access-Acceptpackets are sent from a server to a client to indicate a successful authentication.Access-Rejectpackets are sent from a server to a client to indicate a failed authentication.Access-Challengepackets are sent from a server to a client to solicit more information from the entity being authenticated.
Each packet type defines:
A set of fields that must be included
Other fields that can be included to convey:
• Additional requirements • Information about the context of the conversation • Attributes of the entity after successful authentication
For example, an Access-Request packet should always contain user name and password fields. It can contain other fields that provide information about the client making the request, such as inclusion of the optional State field indicates that a packet is part of an authentication conversation already in progress. Its absence indicates the start of a new conversation.
An authentication conversation always begins with an Access-Request packet that does not have a State field. If the RADIUS server only requires the user name and password for authentication, then conversations will complete after the server sends an Access-Accept or Access-Reject packet, depending on whether the authentication credentials were valid.
If more information is required by the server, such as an SMS-relayed one-time password sent to the user's phone, the additional requirement can be solicited using an Access-Challenge response to the client, followed by an Access-Request packet that has a State field that associates it with the existing conversation. The conversation completes with an Access-Accept or Access-Reject packet depending on whether the one-time password supplied in the second request matches the password sent to the user's phone.
This conversational style in which the server accepts, rejects, or solicits more information makes RADIUS an excellent match for leveraging AM's authentication infrastructure. AM performs authentication using chains of authentication modules found in realms.
These modules identify authentication requirements that are conveyed to clients wishing to authenticate. The modules then accept values submitted by the user for verification. The mechanism for modules to convey these requirements to AM is through a finite set of constructs known as callbacks. By leveraging AM's flexible and extensible authentication mechanism, organizations can craft an authentication experience suitable for their needs, while using the same mechanisms for both HTTP and RADIUS authentication.
Two AM features support the RADIUS protocol: The RADIUS Server Service and The RADIUS Authentication Module.