Security is configured to achieve the following two aspects of ensuring data protection:
Authentication – Ensures that the user logging in is an authorized user of CGI Advantage and establishes the user’s identity. Authentication verifies that the user or system requesting access is who or what it claims to be. All users are assigned a password that is encrypted and stored, and they must supply this password correctly when logging in.
CGI Advantage requires users to enter User IDs and passwords when they log in. (Users must establish passwords the first time they log in and then change them periodically, based on the password expiration policy that has been set up.) The combination of user ID and password is linked to a security profile and is authenticated against information stored in the CGI Advantage database, or – if your site has implemented a Lightweight Directory Access Protocol (LDAP) server – the authentication check is done against information in the LDAP server. Refer to the "LDAP New User Configuration" topic for more information.
A security administrator can enable the Dual-Factor Authentication feature for a particular user. When this feature is enabled, users must go through a second level of authentication in addition to the password authentication to login to the system. This feature requires users to register an email address or a cell phone number to receive the token sent by the system during login. Refer to the "Dual Factor Authentication User Info" topic for more information.
Authorization – CGI Advantage performs a series of checks to verify whether a particular user has access to perform the action being requested on a system resource, such as a tab, transaction, reference page, inquiry page, and so forth. The level of security checking implemented depends on the complexity of your site’s security requirements. When a user performs an action – for example, opens a page or attempts to save a transaction – CGI Advantage authorizes the action. For example, if a user attempts to validate a Purchase Order for the Department of Transportation, CGI Advantage determines whether this combination of user, action, and department is valid.
CGI Advantage makes use of Java Cryptography Architecture (JCA), Java Cryptography Extension (JCE), and Java Authentication and Authorization Services (JAAS) for user authentication and encryption of passwords that are stored in the system. To assist in this, a keystore containing a public/private key pair is created at the time of installation (see the CGI Advantage Installation Guide for more details). The Advantage Administration application uses the keystore to encrypt user email passwords for all other Advantage applications. The keystore itself is protected by a password, while the public/private key pair is protected by an alias and a password that is either provided by the user or randomly generated at the time of installation. The alias is used to distinguish among the different key entries in the keystore. The keystore is a file whose location is defined by an entry, KeyStoreLoc and the password that is used to protect the keystore is defined by the entry KeyStorePassword. The alias for the keys stored in the keystore is defined by the entry EncryptionKeyAlias and the password for the alias is defined by the entry EncryptionKeyPswd. These settings can be found in the system’s initialization parameter file, ADV30Params.ini. They are set once at the time of installation, and are typically not changed.
It is recommended that the keystore file be secured to prevent accidental deletion. Also, a backup of this file should be maintained so that it can be retrieved in the case of accidental deletion.
As with other areas of CGI Advantage, data is delivered with the first three of the four components of security listed below:
Application Resources – the pages, jobs, and other entities that are secured
Resource Groups – groupings of application resources into like sets for similar security rules because the number of resources is extensive.
Security Roles – groupings of users into like sets for similar security rules, which are often called User Roles. These should not be confused with Business Roles. Although in some cases they may be the same, in many instances they are not equal.
Users – individual users of the application that are assigned into security roles. The only user delivered is the System Administrator (User ID of sa).
Although there are many secondary parts of security setup, the fifth major component is the connection of resource groups and security roles together to define access, approval, and other system actions. These setup pages, or reference pages, will be covered first in this guide before discussing the specialized transaction that brings all the reference data into a transaction model to enable workflow.