Applies To:
Show Versions
BIG-IP AAM
- 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP APM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP Analytics
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP Link Controller
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP LTM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP AFM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP PEM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP DNS
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP ASM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
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.
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.
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.
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.
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.
