Applies To:
Show Versions
BIG-IP LTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Remote Server Authentication Profiles
Introduction to authentication profiles
A significant feature of BIG-IP® Local Traffic Manager™ 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, Local Traffic Manager 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
Local Traffic Manager™ authentication modules that you can implement for remote authentication are:
- Lightweight Directory Access Protocol (LDAP)
- Local Traffic Manager 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)
- Local Traffic Manager 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+
- Local Traffic Manager 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
- Local Traffic Manager 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)
- Local Traffic Manager 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)
- Local Traffic Manager can use CRL distribution points to determine revocation status.
- Kerberos Delegation
- Local Traffic Manager can authenticate application traffic when you are using Microsoft Windows Integrated Authentication.
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, Local Traffic Manager™ 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 Local Traffic Manager 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 Local Traffic Manager 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, Local Traffic Manager™ 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, Local Traffic Manager™ 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, Local Traffic Manager™ 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 setting 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 Local Traffic Manager (LTM®) 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, LTM 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 OCSP authentication module checks the revocation status of an SSL certificate, as part of authenticating that certificate.
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. A CRL is a list of revoked client certificates, which a server system can check during the process of verifying a client certificate.
You implement an SSL OCSP authentication module when you want to use OCSP instead of a CRL as the mechanism for checking the revocation status of SSL certificates.
Local Traffic Manager™ supports both CRLs and the OCSP protocol. If you want to use CRLs instead of OCSP, you configure an SSL profile.
For more information on OCSP, see RFC 2560 at URL http://www.ietf.org.
Using OCSP to check on the revocation status of client certificates offers distinct advantages over the use of a CRL.
The limitations of CRLs
When presented with a client certificate, Local Traffic Manager 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 benefits of OCSP
OCSP ensures that Local Traffic Manager always obtains real-time revocation status during the certificate verification process.
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.
How OCSP works
In general, after receiving an SSL certificate from a client application, the BIG-IP system (acting as an OCSP client) requests certificate revocation status from an OCSP responder, and then blocks the connection until it receives status from that responder. If the status from the responder shows that the certificate is revoked, Local Traffic Manager rejects the certificate and denies the connection. If the status from the responder shows that the certificate is still valid, Local Traffic Manager continues with its normal certificate verification process to authenticate the client application.
More specifically, when an application client sends a certificate for authentication, the BIG-IP system follows this process:
- First, the BIG-IP system checks that the signer of the certificate is listed in the trusted CAs file.
- If the certificate is listed, the BIG-IP system then checks to see if the certificate is revoked. Without OCSP, if the CRL option is configured on the BIG-IP system, the BIG-IP system checks revocation status by reading the certificate revocation list (CRL). With OCSP, however, the BIG-IP system bypasses the CRL and prepares to send a revocation status request to the appropriate OCSP responder.
- Next, the BIG-IP system queries the first responder, even if the responder does not match the certificate authority that signed the client certificate. However, if the first responder fails with a connection error, the BIG-IP system queries the next responder.
- Next, the BIG-IP system attempts to match that CA with a CA listed in an SSL OCSP profile.
- If a match exists, the BIG-IP system checks the target URL within the client certificate’s AuthorityInfoAccess (AIA) field (if the field exists), and uses that URL to send the request for certificate revocation status to the OCSP responder.
- If the Ignore AIA parameter is enabled within the SSL OCSP profile, then the BIG-IP system instead uses the URL specified in the url parameter of the matching SSL OCSP profile to send the request for certificate revocation status.
- If no match exists, the BIG-IP system checks the calist setting of another SSL OCSP profile defined on the system. If all SSL OCSP profiles are checked and no match is found, the certificate verification fails, and the BIG-IP system denies the original client request.
- Once the BIG-IP system has received certificate revocation status from a responder, the BIG-IP system, when configured to do so, inserts a certificate status header into the original client request. The name of the certificate status header is SSLClientCertificateStatus.
You must then assign the OCSP profile to a virtual server.
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.
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.
The Kerberos Delegation authentication module
A Kerberos Delegation authentication module is a mechanism for authenticating client connections passing through a BIG-IP® system. You can use this module when you are using Microsoft Windows Integrated Authentication to authenticate application traffic.
The Kerberos Delegation module obtains delegated Kerberos credentials for the client principal, and then retrieves Kerberos credentials for the server-side principal. The Kerberos Delegation module essentially acts as a proxy for Kerberos credentials. That is, when connecting to a server that is inside its domain, the browser client fetches Kerberos credentials. These credentials, known as delegated credentials, are passed to the BIG-IP system, which in turn retrieves credentials for the real server that is on the back end, and passes those credentials back to the client.
