This module enables a user to log in through a personal digital certificate (PDC). The module instance can require the use of the Online Certificate Status Protocol (OCSP) to determine the state of a certificate. Use of the OCSP is optional. The user is granted or denied access to a resource based on whether or not the certificate is valid. The Certificate authentication attributes are realm attributes. The attributes are:
Specifies whether to check if the user certificate presented at login is stored in the LDAP Server. If no match is found, the user is denied access. If a match is found and no other validation is required, the user is granted access. The default is that the Certificate Authentication service does not check for the user certificate.
A certificate stored in the Directory Server is not necessarily valid; it may be on the certificate revocation list. See Match Certificate to CRL. However, the web container may check the validity of the user certificate presented at login.
Specifies the attribute of the certificate's SubjectDN value that will be used to search LDAP for certificates. This attribute must uniquely identify a user entry. The actual value will be used for the search. The default is cn.
Specifies whether to compare the user certificate against the Certificate Revocation List (CRL) in the LDAP Server. The CRL is located by one of the attribute names in the issuer's SubjectDN. If the certificate is on the CRL, the user is denied access; if not, the user is allowed to proceed. This attribute is, by default, not enabled.
Certificates should be revoked when the owner of the certificate has changed status and no longer has the right to use the certificate or when the private key of a certificate owner has been compromised.
When the Certificate authentication module possesses a client certificate for authentication, it checks the configured option first. If CRL validation is enabled, it accesses the CRL from the local Directory Server. If the CRL is valid, it validates the client certificate with the current CRL from the local Directory Server.
If the CRL is not valid or needs to be updated, it retrieves CRLDP information from the client certificate and gets a new CRL from the CRLDP and replaces the old CRL with a new one. If the CRL is not valid or needs to be updated but the client certificate does not have CRLDP, it retrieves IssuingDP information from the current CRL and gets the new CRL from the IssuingDP and replaces the old CRL with a new one. It then validates the client certificate with this new CRL.
Specifies the attribute of the received certificate's issuer subjectDN value that will be used to search LDAP for CRLs. This field is used only when the Match Certificate to CRL attribute is enabled. The actual value will be used for the search. The default is cn.
Specifies the HTTP parameters for obtaining a CRL from a servlet for a CRL update. Contact the administrator of your CA for these parameters.
Enables OCSP validation to be performed by contacting the corresponding OCSP responder. The OCSP responder is decided as follows during runtime:
If com.sun.identity.authentication.ocspCheck is true and the OCSP responder is set in the com.sun.identity.authentication.ocsp.repsonder.url attribute, the value of the attribute will be used as the OCSP responder.
If com.sun.identity.authentication.ocspCheck is set to true and If the value of the attribute is not set in the AMConfig.properties file, the OCSP responder presented in your client certificate is used as the OCSP responder.
If com.sun.identity.authentication.ocspCheck is set to false or if com.sum.identity.authentication.ocspCheck is set to true and if an OCSP responder can not be found, no OCSP validation will be performed.
Before enabling OCSP Validation, make sure that the time of the Access Manager machine and the OCSP responder machine are in sync as close as possible. Also, the time on the Access Manager machine must not be behind the time on the OCSP responder. For example:
OCSP responder machine - 12:00:00 pm
Access Manager machine - 12:00:30 pm
Specifies the name and port number of the LDAP server where the certificates are stored. The default value is the host name and port specified when Access Manager was installed. The host name and port of any LDAP Server where the certificates are stored can be used. The format is hostname:port.
Specifies the DN of the node where the search for the user's certificate should start. There is no default value. The field will recognize any valid DN.
Multiple entries must be prefixed by the local server name. The format is as follows:
servername|search dn
For multiple entries:
servername1|search dn servername2|search dn servername3|search dn...
If multiple entries exist under the root organization with the same user ID, then this parameter should be set so that the only one entry can be searched for or found in order to be authenticated. For example, in the case where the agent ID and user ID is same under root org, this parameter should be ou=Agents for the root organization to authenticate using Agent ID and ou=People, for the root organization to authenticate using User ID.
This field accepts the DN of the principal user for the LDAP server where the certificates are stored. There is no default value for this field which will recognize any valid DN. The principal user must be authorized to read, and search certificate information stored in the Directory Server.
This field carries the LDAP password associated with the user specified in the LDAP Server Principal User field. There is no default value for this field which will recognize the valid LDAP password for the specified principal user. This value is stored as readable text in the directory.
Confirm the password.
Specifies the attribute in the Directory Server entry that matches the certificate whose value should be used to identify the correct user profile. There is no default value for this field which will recognize any valid attribute in a user entry (cn, sn, and so forth) that can be used as the UserID.
Specifies whether to use SSL to access the LDAP server. The default is that the Certificate Authentication service does not use SSL for LDAP access.
Specifies which field in the certificate's Subject DN should be used to search for a matching user profile. For example, if you choose email address, the certificate authentication service will search for the user profile that matches the attribute emailAddr in the user certificate. The user logging in then uses the matched profile. The default field is subject CN. The list contains:
email address
subject CN
subject DN
subject UID
other
If the value of the Certificate Field Used to Access User Profile attribute is set to other, then this field specifies the attribute that will be selected from the received certificate's subjectDN value. The authentication service will then search the user profile that matches the value of that attribute.
Defines a list of trusted hosts that can be trusted to send certificates to Access Manager. Access Manager must verify whether the certificate emanated from one of these hosts. This attribute is only used for SSL termination.
Disables the attribute. This is set by default.
Accepts Portal Server Gateway-style certificate authentication from any client IP address.
Lists the IP addresses from which to accept Portal Server Gateway-style certificate authentication requests (the IP Address of the Gateway(s)). The attribute is configurable on an realm basis.
Specifies the port number for the secure socket layer. Currently, this attribute is only used by the Gateway servlet. Before you add or change an SSL Port Number, see the "Policy-Based Resource Management" section in the Access Manager Administration Guide.
This attribute is used only when the Trusted Remote Hosts attribute is set to all or has a specific host name defined. The administrator must specify the http header name for the client certificate that is inserted by the load balancer or SRA.
The authentication level is set separately for each method of authentication. The value indicates how much to trust an authentication mechanism. Once a user has authenticated, this value is stored in the SSO token for the session. When the SSO token is presented to an application the user wants to access, the application uses the stored value to determine whether the level is sufficient to grant the user access. If the authentication level stored in an SSO token does not meet the minimum value required, the application can prompt the user to authenticate again through a service with a higher authentication level. The default value is 0.
If no authentication level is specified, the SSO token stores the value specified in the Core authentication attribute Default Authentication Level.