AAA policies
An AAA (authentication, authorization, audit) policy identifies a set of resources and procedures that determine whether a requesting client is granted access to a specific service, file, or document. AAA policies are similar to filters that accept or deny a specific client request.
AAA policies are powerful and flexible. They support a range of authentication and authorization mechanisms. You can mix and match multiple authentication and authorization mechanisms in a single policy. For example, one AAA policy can use a single RADIUS server to provide authentication and authorization services. Another policy can authenticate with RADIUS, map RADIUS credentials to an LDAP group with an XML file, and authorize with LDAP.
The following figure shows the basic processing for an AAA policy.
Initial processing, which is common to all policies, consists of extracting the claimed identity of the service requester and the requested resource from an incoming message and its protocol envelope. As you define an AAA policy, extraction methods are specified by a series of choices that enable one or more identity and resource extraction methods. A wide range of identity and resource extraction methods are supported. Identities, for example, can be based on IP addresses, account names and passwords (forms), SAML assertions, social login policy, or JSON Web Token (JWT). Requested resource, for example, can be specified by an HTTP URL, a namespace, or a WSDL method.
After the AAA policy extracts the service requester identity and resource, it authenticates the claimed identity. Authentication is most commonly accomplished through an external service (for example, a RADIUS or LDAP server), but custom processing methods, such as site-specific XML or XPath based solutions, are supported. During policy definition, you select a single authentication method, and, depending on the selected method, provide more needed information.
Successful server-based authentication generates a set of credentials that attest to the identity of the service requester. You can then map these credentials to a set that is more appropriate to the authorization method. You can accomplish this mapping through an XPath expression, an XML mapping file, or a custom method.
As with identity credentials, the extracted resource name can be mapped to a more appropriate authorization method. The methods to achieve this mapping are the same as the methods for credential mapping.
The resulting credentials, along with the resultant resource name, are the basis for client authorization. Client authorization determines whether the identified client has access to the requested resource.
While you can use the same method for both authentication and authorization, you do not need to. Different authentication and authorization methods are often employed in real-world situations. If different methods are used, it might be necessary to map credentials from the authentication phase to a format that is congruent with a different authorization method. For example, you might want to map an authenticated account name-password to an LDAP group.
Like authentication, authorization commonly uses an external service (for example, an LDAP server). However, other custom processing methods, such as site-specific XML or XPath based solutions, are supported. Authorization definition mirrors that of authentication. During policy definition, you select a single authorization method and provide a minimum of method-specific data.
If either authentication or authorization denies access, the AAA policy generates an error, which is returned to the calling entity (which might be the client that submits the request). This error can be handled, as with any other errors in document processing, by an on-error action or an Error rule. Either method allows for the creation of custom error messages.