Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Service Manager9.51

Administer > System security > Common Access Card (CAC) sign-on

Common Access Card (CAC) sign-on

Starting with version 9.32, the Service Manager web client supports CAC sign-on. System Administrators can configure the Service Manager server and web client to automatically log on using CAC authentication. CAC sign-on enables users to log in to the web client directly with a smart card that stores a valid user certificate, and users only need to enter a card PIN, instead of a user name and password.

Note The Service Manager Windows client does not support CAC sign-on.

Supported smart cards

During CAC sign-on, the Service Manager web tier gets access to the user authentication public certificate and its counterpart private key through the underlying client crypto architecture. In other words, Service Manager does not directly communicate with the card reader. Technically, Service Manager supports any smart cards that store an X.509 user authentication certificate and are designed to work with smart card middleware (such as ActivClient) that is installed on the user's computer. The term "Common Access Card (CAC)" in its origin refers to the Unites States Department of Defense (DoD) issued cards; however, in the Service Manager documentation the term CAC is used in a broader scope and refers to any of the supported smart cards. Two examples of such smart cards are the Common Access Card issued by DoD and Personal Identity Verification (PIV) cards issued by other US Government agencies.

CAC authentication

A CAC smart card enables two-factor authentication: the CARD being something you have, and the CAC PIN being something you know. The CAC stores, in a secure way, the card holder’s public certificates and its corresponding private keys. One of those stored certificates with its private keys is used for user authentication. Service Manager uses SSL and CAC authentication, which utilizes the certificate in the CAC card to identify the CAC card holder details and leverages the built-in SSL user authentication abilities to ensure that the CAC owner possess the private key. The certificate key-pair proves that this person is who the person claims to be. For example, if the certificate claims the public key is owned by userX and it was signed by a Certificate Authority (CA), when the certificate is presented assuming Service Manager trusts the CA (which means the CA public key is put in Service Manager's trusted CA store), Service Manager would trust the information and then challenge the person presenting the certificate to prove the person owns the matching private key. If the person provides the proper PIN, that private key is unlocked and then Service Manager authenticates the client as the one detailed in the certificate.

Flexible mapping between distinguished name and login name

During CAC sign-on, a unique attribute in the user's certificate is retrieved as the user's Distinguished Name (DN) and sent to the SM server as the user's login name.

Different organizations may have different definitions for the same attribute in the user's certificate. For example, your organization may use employee ID for Subject.CN, while another may use user's full name for it. In addition, it is also possible that an organization needs to use an Subject Alternative Name (SAN) sub-attribute as DN. For this reason, the Service Manager web tier provides a configuration file (<web tier installation path>\WEB-INF\classes\cacconf.properties), which contains two parameters (certificateFieldExtractDN and certificateOIDMapping) to allow flexible mapping between DN and login name. For more information, see Example: enabling CAC sign-on.

Required configurations

CAC sign-on requires the following configurations:

Both of the Service Manager server and web client have been configured to support CAC sign-on mode.
Two-way SSL is configured between the web server (or the web application server if no web server) and browser.
Two-way SSL is configured between the Service Manager server and all clients (the web and Windows clients, and web services clients such as SRC, Mobility, and other integrated products).

Note Enabling CAC sign-on on the SM server side will affect all SM clients - all SM clients can only connect to the server through two-way SSL.
JDK 1.6 or above is installed on the host machine running the web tier.

Compatibility with other sign-on modes

The following table describes whether or not users can use other sign-on modes when CAC sign-on is enabled in the SM server and web client.

Mode	Description
Basic Authentication	Web client: Users can no longer log in to the web client by entering a user name and password (that is, using basic authentication). It is impossible that some web client users use CAC sign-on while some others use basic authentication. All users must use CAC sign-on. Windows client: Users can log in to the Windows client only with basic authentication, but two-way SSL authentication is required between the server and Windows client.
Trusted Sign-On (TSO)	When both CAC sign-on and TSO are configured in the same web tier, CAC sign-on takes precedence. For this reason, do not enable CAC sign-on and TSO in the same web tier at the same time.
Lightweight Single Sign-On (LW-SSO)	The following discussion assumes a scenario where Product A (which does not support CAC access) is integrated with Service Manager and LW-SSO are enabled on both product sides. Outgoing LW-SSO: SM web client users can directly access product A through LW-SSO. In other words, outgoing LW-SSO from the web tier works well. Incoming LW-SSO: Incoming LW-SSO is ignored, and users can only access SM from product A with a CAC.

Mode

Description

Basic Authentication

Web client: Users can no longer log in to the web client by entering a user name and password (that is, using basic authentication). It is impossible that some web client users use CAC sign-on while some others use basic authentication. All users must use CAC sign-on.

Windows client: Users can log in to the Windows client only with basic authentication, but two-way SSL authentication is required between the server and Windows client.

Trusted Sign-On (TSO)

When both CAC sign-on and TSO are configured in the same web tier, CAC sign-on takes precedence. For this reason, do not enable CAC sign-on and TSO in the same web tier at the same time.

Lightweight Single Sign-On (LW-SSO)

The following discussion assumes a scenario where Product A (which does not support CAC access) is integrated with Service Manager and LW-SSO are enabled on both product sides.

Outgoing LW-SSO: SM web client users can directly access product A through LW-SSO. In other words, outgoing LW-SSO from the web tier works well.

Incoming LW-SSO: Incoming LW-SSO is ignored, and users can only access SM from product A with a CAC.

Conditions for CAC access

In a CAC sign-on scenario, the Service Manager server grants access to web clients only if the following conditions are met:

The web browser from the client side sends the user certificate to the web server, and then the web server passes the certificate to the web application server.
The user certificate passes the validation by the web tier.
The user's logon credentials match an existing operator record in Service Manager or a valid LDAP source that Service Manager recognizes.
The web client presents a signed SSL certificate.

Note Each Windows client must also present a signed SSL certificate to the server.

CAC connection process

The following figure depicts the connection process between a web server, a web application server, and the Service Manager server in a CAC sign-on scenario.

The following describes how the process works:

The user inserts a CAC into a card reader.
The smart card middleware (such as ActivClient) automatically loads the user's personal certificate ("user certificate") from the CAC to the browser.
The browser prompts the user to select an installed certificate to log in.
The user selects the user certificate to log in.
The browser prompts the user to enter the PIN of the user's CAC.
The user enters the correct PIN.
The web server passes the user certificate to the web application server for validation based on a pre-configured validation strategy, which can include any combinations of the following checks except that at least one of the following options must be included: using a local CRL, using an online CRL, and using the OCSP.
- Check if the issuer is from a trusted CA (Certificate Authority)
- Check if the certificate is revoked using a local Certificate Revocation List (CRL)
- Check if the certificate is revoked using an online CRL
- Check if the certificate is revoked using the Online Certificate Status Protocol (OCSP)
- Check if the certificate has expired
- Check if the certificate type is Smart Card
The web application server extracts the Distinguished Name (DN) from the user certificate and sends the DN as the user's user name to the Service Manager server.
The server verifies the DN against the name field in the operator table (when LDAP is not configured) or against the LDAP attribute mapped to this field (if LDAP is configured). If the DN value matches an operator name, the server logs the user in; otherwise the server rejects the login request.

Send Help Center feedback