Using TrafficScript Rules with Remote LDAP Authenticators
To use authentication in your TrafficScript rules, first create remote LDAP authentication service definitions in the Authenticators Catalog (Catalogs > Authenticators). Authenticators created in this manner can be accessed through the auth.query() function from within a TrafficScript rule. This rule can then be added to a virtual server handling the service to be authenticated.
TrafficScript is a license-controlled feature. The functionality described here might not be available in all product variants. Contact your support provider for more details.
Configuring Authenticators
To create and edit remote LDAP authenticator records, use the Catalogs > Authenticators page of the Admin UI. To create a new authenticator, provide a name, host, and port in the “Create New Authenticator” section, then click Create Authenticator. The Virtual Traffic Manager displays the Authenticator edit page, containing all basic and LDAP settings for the new authenticator. You must complete configuration of all LDAP settings for your authenticator to work correctly.
The Authenticator edit page contains the following configuration keys:
Setting | Description |
|---|---|
Name | The identifying name given to this authenticator. This name will be used in the auth.query() function call, within an authenticating TrafficScript rule. If the authenticator is renamed here, any rules referencing this authenticator will be automatically updated to use the new name. |
Host | The host-name or IP address of the LDAP server to connect to. |
Port | The port of the LDAP server to connect to. |
Note | A description of this authenticator. |
ldap!bind!dn | The Distinguished Name (DN) of the 'bind' user. The bind user is used to contact the LDAP server and search for the record belonging to the user being authenticated. The bind user must have permission to search for and read user records on the LDAP server. If no bind user is specified then the Virtual Traffic Manager will attempt an anonymous login to search for the user being authenticated. |
ldap!bind!password | The password for the bind user specified in ldap!bind!dn. |
ldap!filter | A filter used to extract the unique user record located under the base DN. The string %u will be replaced by the username supplied when the authenticator is invoked. Examples of common LDAP filters include sAMAccountName=%u for Active Directory, or uid=%u for some UNIX LDAP schemas. |
ldap!filter!basedn | The base Distinguished Name (DN) under which the Virtual Traffic Manager will search for the record of the user being authenticated. The entries for all users that are to be authenticated by this LDAP authenticator must appear under the DN specified here. A typical base DN might be OU=users, DC=mycompany, DC=local. |
ldap!attr | If the Virtual Traffic Manager finds a record for the user being authenticated on the LDAP server it can fetch back additional information from that record. This information can be used to perform additional checks on the user being authenticated, such as restricting access based on which group the user belongs to. To fetch back specific attributes from the user's record, a space- or comma-separated list of attribute names can be specified in the ldap!attr setting. To fetch back all attributes from the user's record, set ldap!attr to '*'. If the setting is blank, no additional attributes will be retrieved from the server. Any attributes retrieved from the user's record will be available in the return value from the TrafficScript function that requested the authentication. |
ldap!ssl | This setting determines whether or not the connection to the LDAP server will be SSL-encrypted. The method by which the SSL connection is established can be specified in the ldap!ssl!type setting. |
ldap!ssl!type | This setting specifies the method by which an SSL connection to the LDAP server is established. It is used only if ldap!ssl is set to “Yes”. The available methods are: LDAPS: The Virtual Traffic Manager will establish a secure connection to the LDAP server before any LDAP messages are sent. Start TLS: The Virtual Traffic Manager will use the LDAPv3 Transport Layer Security extension to establish a secure connection to the server. |
ldap!ssl!cert | When connecting to the remote LDAP server over SSL, the Virtual Traffic Manager ensures that the server's certificate is signed by the certificate authority specified by this setting. If the server sends a certificate that is not signed by the certificate authority specified here, or the certificate does not match the value specified as the server's identity given in Host, an error is returned to the TrafficScript function using the authenticator. If no certificate authority is specified, the server's certificate is not validated. |
Configuring the TrafficScript Rule
To use remote authentication within a virtual server, assign an authentication rule to it as a request rule. This rule should contain a call to the function auth.query() with the arguments shown here:
auth.query( authenticator, user, [password] );This queries the named authenticator for information about user and, if supplied, checks that password matches the password on record for that user. It returns a hash containing two values, “OK” and “Error”, which are set according to the results of the verification. The result can also contain additional information returned by the authenticator, such as the Distinguished Name of the user that was queried. Refer to the TrafficScript Reference for more details.
To learn more about creating TrafficScript rules, see TrafficScriptTrafficScript Rules.
The example below shows how you might use the auth.query() function to provide user verification based on a previously created Authenticator called “ldap”:
# Verify the user's password using an LDAP
# authenticator called 'ldap'
$auth = auth.query( "ldap", $user, $pass );
if( $auth['Error'] ) {
log.error( "Error with authenticator 'ldap': " . $auth['Error'] );
connection.discard();
} else if( !$auth['OK'] ) {
# Unauthorised
http.sendResponse( "403 Permission Denied", "text/html",
"Incorrect username or password", "" );
}
# Allow through members of the 'admin' group using
# the 'group' attribute returned by the authenticator
if( $auth['group'] != "admin" ) {
http.sendResponse( "403 Permission Denied","text/html",
"You do not have permission to view this page","" );
}Configuring the Virtual Server
Once you have a rule with the appropriate settings configured, you must assign it to the virtual server on which you want to enable authentication:
- Go to the Services > Virtual Servers section of the Admin UI and select the virtual server on which you want to enable authentication.
- Click the Rules section.
- Under “Request Rules”, select your authentication rule and click Add Rule.