This article contains the following topics:
This article contains the following topics:
CA SDM provides a user authentication solution that you can modify as part of the access type. The same authentication is used by all CA SDM interfaces and by other CA products.
Authentication is flexible, allowing you to take advantage of external authentication mechanisms, such as Windows, HTTPD user validation or LDAP authentication. You can also select from a variety of internal authentication options, including operating system password, PIN, guest user access, or no access at all.
How CA SDM Authenticates Users
CA SDM authenticates users based on the user ID defined in their contact record. The product also does the following when a user requests access to the system:
- If an external user ID is available (from HTTPD or Windows validation), CA SDM looks up the contact by login ID. If the contact is found and has an access type that permits external authentication, the user is allowed into the product.
- If there was no successful external authentication, CA SDM prompts the user for a user ID and password. The product looks up a contact record for the user ID, obtains the access type, and then authenticates the user as specified by the access type.
Many installations find the predefined access types define authentication that is reasonable for that type of user; however, in some cases you may need to modify the authentication information for a predefined access type or define a new access type to handle a different authentication method for some of your users. You should review the authentication settings for the predefined access types to determine if they meet your needs, or if you need to modify them, or define additional types.
CA SDM permits users to access the system without supplying a user ID if all of the following conditions are met:
- External authentication is set for the user.
- The user's externally authenticated user ID is associated with a contact in your contact table.
- The contact record has an access type whose authentication definition permits external authentication.
External authentication does not permit users to access the system in the following cases:
- A user attempts access through a non-secure server.
- A user attempts access but is assigned to an access type that does not allow external authentication.
None of the predefined access types use external authentication. If you want to use external authentication for users, consider modifying the employee, analyst, and administrator access types to set external authentication. Your individual site requirements and different types of users determine whether to allow external authentication. When external authentication is used, the server configuration controls the access to files and directories. When you define authentication for an access type, you can decide the usage as follows:
- Do not use any external authentication that is already implemented, such as the user login on Windows or validation by the HTTPD server.
- Use the authentication that is implemented and allow or deny access based on it.
If external authentication is not allowed, the user is authenticated based on the validation type that you specify.
Following are some examples of external authentication:
- If a user who has administrator access logs into a Windows computer, the user can perform administrative tasks without re-entering any login information.
- If a user who has HTTPD server validation, the user can access the web interface without re-entering any login information. Because the administrator access type specifies the analyst web user type, the appropriate web interface for the analyst is presented automatically.
Validation types authenticate users only under the following circumstances:
- The user access type does not permit external authentication.
- The user access type permits external authentication, but the user has not been validated externally (for example, the user has attempted access through a nonsecure server).
CA SDM provides you with the following validation options:
- No Access-- Users of this type have no access unless external authentication is allowed and is valid.
- Open-- Users of this type have access, with no additional authentication required.
- OS-- Users of this type enter their operating system password for access. The operating system used for validation is the one running User Validation Host. This option is the default validation type for the administrator, analyst, and employee access types.
- PIN-- Users of this type gain access by entering the correct value for the PIN field in their contact record as their password. You define the PIN field by entering the field attribute name when you select PIN as the validation type. PIN is the default validation type for the customer access type, which uses the value in the customer ID (contact_num) field as the PIN.
Logged In User Counts and Session Counts
The following KPIs count the number of unique licensed users that are logged in to the system (for example, CA SDM Web UI, SOAP Web Services, REST Web Services, and so on), regardless of how many sessions each user has opened:
For a licensed user, ensure that the Licensed? check box is selected from the Access type page of the contact (navigate to Security and Role Management, Access Type on the Administration tab and search for the contact).
The following KPIs count the numbers of unique unlicensed users that are logged in to the system, regardless of how many sessions each user has opened:
The following KPIs count the number of unique sessions that started during the interval:
For more information about the KPI description, see the KPI detail page (navigate to Service Desk, KPIs on the Administration tab and search for the KPI). For more information about how these KPIs count from different session types, see the How KPIs Count from Different Session Types topic.
How KPIs Count from Different Session Types
There are different session types that are defined in the system. The following table shows how KPIs count these sessions:
Note:All predefined KPIs are installed as Inactive. For a KPI to begin functioning in your system, it must be set to Active. Navigate to Service Desk, KPIs on the Administration tab and search for the inactive KPI. Open the KPI and click Activate.
Multiple versions of a KPI with the same name cannot be active at the same time.
Session Type Description
Counted by KPIs
Web browser session
Java client session
SOAP Web services session
Server utility session
Knowledge Chat session
Mail Server session
Custom Application session
PDA Client session
REST Web Services Session
Example: KPIs calculating user counts
One licensed (that have the Licensed? check box selected) and two unlicensed end users are logged into the web self-service interface and reviewing some announcements.
At the same time five licensed analysts (that have the Licensed? check box selected) are logged into the analyst interface and working on incidents. One of the analysts also logs in to the SOAP Web Services interface.
- The webConcurrentLicenseCt KPI shows a count of six, meaning that six licenses are currently being used, irrespective of the number of interfaces each user is using.
- The webConcurrentNonLicenseCt KPI shows the count of two, which means that two unlicensed users are logged on to the system, irrespective of the number of interfaces each user is using.
- The webSessionCt KPI shows a count of eight, meaning that eight total users are logged in to the CA SDM Web UI.
- The webSOAPSessionCt KPI shows a count of one, meaning that one user is logged in to the SOAP Web Services interface.
(Applicable for advanced availability configuration only) Example: KPIs calculating user counts from different nodes
A licensed analyst logs in to the analyst interface from the background server and works on incidents. The same analyst logs in to the analyst interface from the application server. The webConcurrentLicenseCt KPI shows a count of one, meaning that one license is currently being used, irrespective of the number of nodes or servers the user has logged in from.