Manual Chapter :
Authentication Profiles
Applies To:
Show Versions
BIG-IP APM
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP Analytics
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP LTM
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP PEM
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP AFM
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP DNS
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP ASM
- 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.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.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.
