Every installation of Enterprise Security, whether in a standalone or multimachine environment, has a central database that stores all of the user’s authorization and authentication information, such as user name and password credentials, digital certificates, and access permissions to the enterprise components. Unless you have installed and configured a third-party LDAP server to store authorization and authentication information, the database that stores this information is called the Access Control Database, or ACDB.
For information on configuring your environment to use a third-party LDAP server, see Chapter 10, “Configuring LDAP Authentication.” For information on configuring single sign-on capabilities through the Portal Interface, see Chapter 12, “Certificate-Based Authentication.”
In addition to the information that is automatically inserted into the database, there is configurable information that is defined and implemented by the PSO. The PSO configures user-specific and asset-specific information using Enterprise Security Manager—see “Enterprise Security Manager”.
The ACDB stores information for each user, role, and asset. Figure 1-5 shows the content of a user record.
Figure 1-5: Access Control Database record for a user
Portal user ID – uniquely identifies the user throughout the portal. If you are using digital certificates, this field contains the distinguished name (DN) from the certificate.
Portal authentication information – this field contains the information required to authenticate the user to the portal. It can be a password, a digital certificate, or a call to an authentication PKI.
User profile – contains other information specific to the user, including:
The user’s default roles or organizational associations that can be used for access control decisions in place of the user’s actual identity.
A role can be used in two ways. It can be used in place of the user’s identity. In this case, the system may not need to know who the user is. A company affiliation can be sufficient. A role can also be used when access control decisions are made based on users’ identities and the roles they possess. For example, a branch manager role will have different permissions than a teller role.
Information required for transparent authentication to legacy systems with their own security mechanisms.
The records for roles and assets are similar to those for users. You can define access permissions for roles and then assign roles to users, a process that simplifies security management for large user populations. By defining access permissions for roles to access different assets, you can specify the extent of what a user in that role can do.
