An authentication profile is a set of third-party configuration properties, which are assigned to a connection profile or HTTP access service.
These properties control how clients are authenticated. Messaging connections, such as short message service (SMS) MNCs, do not use connection profiles.
When you create or edit the properties of a connection profile or HTTP access service, you assign an authentication profile. A default System profile comes with the SafeLinx Administrator. You can create other profiles, one for each set of properties that you want to assign to an individual service. Authentication profiles can be chained together by selecting Additional authentication profiles on the Security Tab of Connection Profiles.
- Authenticates a client by using remote authentication dial-in user service (RADIUS). You can configure an extra challenge to a client for a RADIUS user ID and password. If the optional challenge is not configured, this authentication method uses a previously specified user ID and password, such as a SafeLinx Client user ID and password, to authenticate the client. If the challenge is not validated or if the RADIUS authentication fails, an error message is sent to the client.
- Authenticates a client by using LDAP-bind (lightweight directory access protocol) authentication, which does a directory service server (DSS) lookup by using a configurable key field. After the DSS performs an LDAP-bind operation and successfully associates the key field with a distinguished name, the client is authenticated. If the LDAP-bind operation fails, an error message is sent to the client. If you specify System authentication in addition to LDAP-bind, the client is challenged to present credentials (user ID and password) twice.
- Challenges a client for valid credentials by using stored X.509 certificates. If the certificate verification operation fails, an error message is sent to the client. Only connection profiles can use certificate-based authentication profiles.
RADIUS and LDAP-bind authentication profiles enable lightweight third-party authentication (LTPA) and single sign-on (SSO). When a user is authenticated and LTPA is enabled, a token is generated and included in application requests that are made by the user. Other LTPA-aware application servers (including SafeLinx Server) can use this token to authenticate the user. SSO uses the LTPA token to avoid multiple authentication challenges. With SSO enabled, application servers that reside within a single domain and share a user directory can accept authentication information from the token.
- Requires a descriptive name of the profile, IP addresses and port number of the RADIUS servers, and the shared secret, which is the password that authenticates the SafeLinx Server as a network access server to the RADIUS servers. You can also specify whether clients are explicitly challenged for their user ID and password that is used for the RADIUS authentication request.
- Requires a descriptive name of the profile, the directory servers that are used to perform the LDAP-bind operation to authenticate clients, and a maximum idle time that specifies how long to keep the directory service server (DSS) connected. You define a user key field, such as uid or mail, to determine which field is searched in the directory tree. You also specify a base distinguished name (base DN) that is the root or suffix of the directory tree where the search for client authentication resources begins. You can optionally secure the connection between the DSS and the SafeLinx Server by using secure sockets layer (SSL).
Requires a descriptive name of the profile and determines how you want to verify the client certificate authenticity.You can verify the client certificate by checking:
- A validity period to make sure that the date is within a valid range
- The trust relationship with the user through the certificate authority (CA) certificates that
are stored in a key database. Additionally, checking that the CA did not revoke a user's
certificate, specify a directory in the local file system from which the SafeLinx Server can check
for certificate revocation lists (CRLs).Note: The
removeFromCRLreason code in the delta CRL entry extensions is not supported. To remove a certificate from a CRL, issue a new base and delta CRL that do not contain the unrevoked certificate. Delta CRLs are also processed following the specification in section 5.2.3 of IETF RFC 3280.
- The certificate subject key by using either:
- Portions of the certificate subject key against portions of the user record as stored in the SafeLinx Server directory server service (DSS). You form a rule in which you specify which attributes can be attempted for a match.
- The subject key in a specified DSS other than the SafeLinx Server DSS. Optionally, you can also specify to verify the subject key against whether a user is in a specific group or whether a specific group includes that user.
For RADIUS and LDAP-bind profiles, if you want to enable LTPA and SSO, specify the lifetime in minutes of the LTPA token, the SSO domain, and whether SSO can use secure sockets layer (SSL) connections only.
To add an authentication profile, right-click the OU in which you want to add the profile, then clickand select which type of profile you want to use.