Manual Chapter : Authentication Profiles

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP APM

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP Analytics

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP Link Controller

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP LTM

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP AFM

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP PEM

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP DNS

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP ASM

  • 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
Manual Chapter

Authentication Profiles

Introduction to authentication profiles

A significant feature of the BIG-IP® system is its ability to support Pluggable Authentication Module (PAM) technology.
PAM
technology allows you to choose from a number of different authentication and authorization schemes to use to authenticate or authorize network traffic.
The goal of PAM technology is to separate an application, such as the BIG-IP system, from its underlying authentication technology. This means that you can dictate the particular authentication/authorization technology that you want the BIG-IP system to use to authenticate application traffic coming into the BIG-IP system.
To this end, the BIG-IP system offers several authentication schemes, known as authentication modules. These
authentication modules
allow you to use a remote system to authenticate or authorize application requests that pass through the BIG-IP system.
Always configure the LDAP authentication module to use SSL, to avoid potential security risks.
The BIG-IP system normally routes remote authentication traffic through a Traffic Management Microkernel (TMM) switch interface (that is, an interface associated with a VLAN and a self IP address), rather than through the management interface. Therefore, if the TMM service is stopped for any reason, remote authentication is not available until the service is running again.

BIG-IP system authentication modules

The BIG-IP® system authentication modules that you can implement for remote authentication are:
Lightweight Directory Access Protocol (LDAP)
The BIG-IP system can authenticate or authorize network traffic using data stored on a remote LDAP server or a Microsoft Windows Active Directory server. Client credentials are based on basic HTTP authentication (user name and password).
Remote Authentication Dial-In User Service (RADIUS)
The BIG-IP system can authenticate network traffic using data stored on a remote RADIUS server. Client credentials are based on basic HTTP authentication (user name and password).
TACACS+
The BIG-IP system can authenticate network traffic using data stored on a remote TACACS+ server. Client credentials are based on basic HTTP authentication (user name and password).
SSL client certificate LDAP
The BIG-IP system can authorize network traffic using data stored on a remote LDAP server. Client credentials are based on SSL certificates, as well as defined user groups and roles.
Online Certificate Status Protocol (OCSP)
The BIG-IP system can check on the revocation status of a client certificate using data stored on a remote OCSP server. Client credentials are based on SSL certificates.
Certificate Revocation List Distribution Point (CRLDP)
The BIG-IP system can use CRL distribution points to determine revocation status.
When you create remote authentication objects and profiles, the BIG-IP® system places them into your current administrative partition. Note that the default profile always resides in partition
Common
.

The LDAP authentication module

An
LDAP authentication module
is a mechanism for authenticating or authorizing client connections passing through a BIG-IP® system. This module is useful when your authentication or authorization data is stored on a remote LDAP server or a Microsoft Windows Active Directory server, and you want the client credentials to be based on basic HTTP authentication (that is, user name and password).
With the LDAP authentication module, the BIG-IP® system can indicate that the authentication was a success or failure, or that the LDAP server needs a credential of some sort.
Additionally, the system can take some action based on certain information that the server returns in the LDAP query response. For example, LDAP response information can indicate the user’s group membership, or it can indicate that the user’s password has expired. To configure the BIG-IP system to return specific data in an LDAP response, you can write an iRule, using the commands
AUTH::subscribe
,
AUTH::unsubscribe
, and
AUTH::response_data
. For more information, see the F5 Networks DevCentral web site,
http://devcentral.f5.com
.
Always configure the LDP authentication module to use SSL, to avoid potential security risks.

The RADIUS authentication module

A
RADIUS authentication module
is a mechanism for authenticating client connections passing through a BIG-IP® system. You use this module when your authentication data is stored on a remote RADIUS server. In this case, client credentials are based on basic HTTP authentication (that is, user name and password).

The TACACS+ authentication module

A
TACACS+ authentication module
is a mechanism for authenticating client connections passing through a BIG-IP® system. You use this module when your authentication data is stored on a remote TACACS+ server. In this case, client credentials are based on basic HTTP authentication (that is, user name and password).

The SSL client certificate LDAP authentication module

An
SSL client certificate LDAP authentication module
is a mechanism for authorizing client connections passing through a BIG-IP® system. With the SSL client certificate LDAP authentication module, you can use a remote LDAP server to impose access control on application traffic. The module bases this access control on SSL certificates, as well as user groups and roles that you specify.
With the SSL client certificate LDAP authentication module, Local Traffic Manager can indicate that the authorization was a success or failure, or that the LDAP server needs a credential of some sort.
Additionally, the system can take some action based on certain information that the server returns in the LDAP query response. For example, LDAP response information can indicate the user’s group membership, or it can indicate that the user’s password has expired. To configure the BIG-IP system to return specific data in an LDAP response, you can write an iRule, using the commands
AUTH::subscribe
,
AUTH::unsubscribe
, and
AUTH::response_data
. For more information, see the F5 Networks DevCentral web site,
http://devcentral.f5.com
.

Search results and corresponding authorization status

This table shows the results of certificate-based authorization being performed.
Result of search
Authorization status
No records match
Authorization fails
One record matches
Authorization succeeds and is subject to groups and roles
Two or more records match
Authorization fails, due to invalid database entries

SSL client certificate authorization

Before you can implement an SSL client certificate LDAP module, you must understand the two different types of credentials that the BIG-IP® system uses to authorize application traffic using data on a remote LDAP server. These two types of credentials are:
  • SSL certificates
  • Groups and roles
With SSL client certificate LDAP authorization, the BIG-IP® system can authorize clients based on signed client certificates issued by trusted CAs. Then, to further enhance the ability of the system to authorize client requests, you can also specify groups and roles. Basing authorization on certificates as well as groups and roles provides the flexibility you need to control client access to system resources.

SSL certificates for LDAP authorization

During the process of authorizing a client, the BIG-IP® system must search the LDAP database. When using certificate-based authorization, the system can search the LDAP database in three ways:
User
If certificates are not stored in the LDAP database, you can configure the system to extract a user name from the certificate presented as part of the incoming client request. The system then checks to see if an entry for the user exists in the LDAP database. This scenario is a good choice for a company that acts as its own Certificate Authority, where the company is assured that if the certificate is verified, then the user is authorized.
Certificate Map
If you create an object and class that map certificates to users in the LDAP database, you can then configure the system to search for a certificate in the map, and retrieve a user from that map. The system then checks to ensure that the user in the LDAP database is a valid user.
Certificate
Many LDAP server environments already incorporate certificates into the user information stored in the LDAP database. One way of configuring authorization in LDAP server environments is to configure the system to compare an incoming certificate to the certificate stored in the LDAP database for the user associated with the client request. If the certificate is found in the user’s LDAP profile, access is granted to the user, and the request is granted.

Groups and roles for LDAP authorization

In addition to enabling certificate-based authorization, you can also configure authorization based on groups and roles.
Groups
Because LDAP servers already have the concept and structure of groups built into them, the BIG-IP® system can include groups in its authorization feature. To enable the use of groups for authorization purposes, you must indicate the base and scope under which the system will search for groups in the LDAP database. Also, you must specify values for a group name and a member name. Once you have completed these tasks, the system can search through the list of valid groups until a group is found that has the current user as a member.
Roles
Unlike a group, a role is a setting directly associated with a user. Any role-based authorization that the BIG-IP system performs depends on the LDAP database having the concept of roles built into it. To determine if a user should be granted access to a resource, the BIG-IP system searches through the roles assigned to the user and attempts to match that role to a valid role defined by the administrator.

The SSL OCSP authentication module

An
SSL OCSP authentication module
is a mechanism for authenticating client connections passing through a BIG-IP® system. More specifically, an SSL
Online Certificate Status Protocol (OCSP)
authentication module checks the revocation status of an SSL certificate, as part of authenticating that certificate.
A single SSL OCSP profile can target a specific responder, or multiple SSL OCSP profiles can target the same responder. Each responder itself is associated with a certificate authority (CA), and multiple responders can be associated with the same CA.
The BIG-IP system allows you to enable both the CRL and the OCSP options. Most users need to enable either one or the other, but not both. However, in the rare case that you want to enable both options, be aware that both the search of the CRL file, and the connection to the responder must be successful. Otherwise, the BIG-IP system cannot obtain status.
Note that an OCSP responder object is an object that you create that includes a URL for an external OCSP responder. You must create a separate OCSP responder object for each external OCSP responder. When you subsequently create an OCSP configuration object, the configuration object contains a reference to any OCSP responder objects that you have created.
If you want to use CRLs instead of OCSP, you configure an SSL profile.

What is OCSP?

Online Certificate Status Protocol (OCSP)
is a third-party software application and industry-standard protocol that offers an alternative to a certificate revocation list (CRL) when using public-key technology. On the BIG-IP system, OCSP ensures that the BIG-IP system always obtains real-time revocation status during the certificate verification process. A
CRL
is a list of revoked client certificates, which a server system can check during the process of verifying a client certificate.
OCSP is based on a client/server model, where a client system requests revocation status of a certificate, and a server system sends the response. Thus, when you implement the SSL OCSP authentication module, the BIG-IP system acts as the OCSP client, and an external system, known as an OCSP responder, acts as the OCSP server. An
OCSP responder
is therefore an external server that sends certificate revocation status, upon request, to the BIG-IP system.
For more information on OCSP, see RFC 2560 at URL
http://www.ietf.org
.

Limitations of Certificate Revocation Lists

Using OCSP to check on the revocation status of client certificates offers distinct advantages over the use of a CRL.
When presented with a client certificate, the BIG-IP system sometimes needs to assess the revocation state of that certificate before accepting the certificate and forwarding the connection to a target server. The standard method of assessing revocation status is a CRL, which is stored in a separate CRL file on each machine in your configuration. Although CRLs are considered to be a standard way of checking revocation status of SSL certificates, a CRL is updated only at fixed intervals, thus presenting a risk that the information in the CRL is outdated at the time that the status check occurs.
Also, having to store a separate CRL file on each machine presents other limitations:
  • All CRL files must be kept in sync.
  • Having a separate CRL file on each machine poses a security risk.
  • Multiple CRL files cannot be administered from a central location.

The CRLDP authentication module

A CRLDP authentication module is a mechanism for authenticating client connections passing through a BIG-IP® system. You implement a CRLDP authentication module when you want the BIG-IP system to use CRL distribution points as the mechanism for checking the revocation status of SSL certificates.
This CRLDP authentication feature is based on a technology known as
Certificate Revocation List Distribution Points (CRLDP)
. CRLDP is an industry-standard protocol that offers an alternative method for checking a standard certificate revocation list (CRL) to determine revocation status. CRLDP is also an alternative to using Online Certificate Status Protocol (OCSP).
A CRLDP authentication module uses CRL distribution points to check the revocation status of an SSL certificate, as part of authenticating that certificate.
CRL distribution points
are a mechanism used to distribute certificate revocation information across a network. More specifically, a distribution point is a Uniform Resource Identifier (URI) or directory name specified in a certificate that identifies how the server obtains CRL information. Distribution points can be used in conjunction with CRLs to configure certificate authorization using any number of LDAP servers.