This chapter provides information about Identity Manager security features, and details steps you can take to further reduce security risks.
Review the following topics to learn more about managing system security with Identity Manager.
Identity Manager helps reduce security risks by providing the following features:
Instant disabling of account access. Identity Manager lets you disable organizations or individual access rights with a single action.
Login session limitations. You can set limitations on concurrent login sessions.
Active risk analysis. Identity Manager scans constantly for security risks such as inactive accounts and suspicious password activity.
Comprehensive password management. Complete and flexible password management capabilities ensure complete access control.
Auditing and reporting to monitor access activities. You can run a full range of reports to deliver targeted information on access activities. (See Chapter 8, Reporting for more information about reporting features.)
Granular Administrative-privilege controls. You can grant and manage administrative control in Identity Manager by assigning a single Capability to a user or a range of administrative duties defined through Admin Roles.
Server key encryption. Identity Manager allows you to create and manage server encryption keys through the Tasks area.
In addition, system architecture seeks to reduce security risks wherever possible. For example, once logged out, you cannot access previously visited pages through your browser’s Back feature.
By default, an Identity Manager user can have concurrent login sessions. You can limit concurrent sessions, however, to one per login application by opening the system configuration object for modification (Editing Identity Manager Configuration Objects) and editing the value of the security.authn.singleLoginSessionPerApp configuration attribute. This attribute is an object that contains one attribute for each login application name (for example, the Administrator Interface, User Interface, or Identity Manager IDE). Changing the value of this attribute to true enforces a single login session for each user.
If enforced, then a user can log in to more than one session; however, only the last logged-in session remains active and valid. If the user performs an action on an invalid session, then he is automatically forced off the session and the session terminates.
Identity Manager offers password management at multiple levels:
Administrative change management
Change a user’s password from multiple locations (Edit User, Find User, or Change Password pages)
Change passwords on any one of a user’s resources with granular resource selection
Administrative password resets
Generate random passwords
Display passwords to the end user or the administrator
User change password
Provide self-service to the end user for password changes at
http://localhost:8080/idm/user
Optionally customize the self-service page to match the end user’s environment
User update data
Set up any user schema attribute to be managed by the end user
User access recovery
Use authentication answers to grant a user access to change his password
Use pass-through authentication to grant a user access by using one of several passwords
Password policies
Use rules to define password parameters
Use pass-through authentication to grant user and administrator access through one or more different passwords.
Identity Manager manages authentication through the implementation of:
Login applications (a collection of login module groups)
Login module groups (an ordered set of login modules)
Login modules (set authentication for each assigned resource and specify one of several success requirements for authentication)
Login applications define a collection of login module groups, which further define the set and order of login modules that will be used when a user logs in to Identity Manager. Each login application comprises one or more login module groups.
At login, the login application checks its set of login module groups. If only one login module group is set, then it is used, and its contained login modules are processed in the group-defined order. If the login application has more than one defined login module group, then Identity Manager checks the login constraint rules applied to each login module group to determine which group to process.
Login constraint rules are applied to login module groups. For each set of login module groups in a login application, only one cannot have a login constraint rule applied to it.
When determining which login module group of a set to process, Identity Manager evaluates the first login module group’s constraint rule. If it succeeds, then it processes that login module group. If it fails, then it evaluates each login module group in turn, until a constraint rule succeeds or a login module group with no constraint rule is evaluated (and subsequently used).
If a login application will contain more than one login module group, then the login module group with no login constraint rules should be placed in the last position of the set.
In the following example of a location-based login constraint rule, the rule gets the IP address of the requester from the HTTP header, and then checks to see if it is located on the 192.168 network. If 192.168. is found in the IP address, then the rule will return a value of true, and this login module group is selected.
<Rule authType=’LoginConstraintRule’ name=’Sample On Local Network’> <match> <ref>remoteAddr</ref> <s>192.168.</s> </match> <MemberObjectGroups> <ObjectRef type=’ObjectGroup’ name=’All’/> </MemberObjectGroups> </Rule> |
From the menu bar, select Security -> Login to access the Login page.
The login application list shows:
Each Identity Manager login application (interface) defined
The login module groups that comprise the login application
The Identity Manager session timeout limits set for each login application
From the Login page you can:
Create custom login applications
Delete custom login applications
Manage login module groups
To edit a login application, select it from the list.
From the Modify Login Application page, you can set a timeout value (limits) for each Identity Manager login session. Select hours, minutes, and seconds, and then click Save. The limits you establish display in the login application list.
You can set session timeouts for each Identity Manager login application. When a user logs in to an Identity Manager application, then the currently configured session timeout value is used to compute the future date and time when the user’s session will time out due to inactivity. This computed date is then stored with the user’s Identity Manager session so that it is available to be checked each time a request is made.
If a login administrator changes a login application session timeout value, then that value will be in effect for all future logins. Existing sessions will time out based on the value in effect when the user logged in.
Values set for HTTP timeout affect all Identity Manager applications and take precedence over the login application session timeout value.
From the Create Login Application and Modify Login Application pages, you can select the Disable option to disable a login application, thereby preventing users from logging in. If a user tries to log in to a disabled application, the user is redirected to an alternate page that states that the application is currently disabled. You can edit the message that displays on this page by editing the custom catalog.
Login applications remain disabled until you deselect the option. As a safeguard, you cannot disable administrator login.
The login module group list shows:
Each login module group
The individual login modules that make up a login module group
Whether a login module group contains constraint rules
From the Login Module Groups page you can create, edit, and delete login module groups. Select a login module group from the list to edit it.
Enter details or make selections for login modules as follows. (Not all options are available for each login module.)
Login success requirement. Select a requirement that applies to this module. Selections are:
Required. The login module is required to succeed. Irrespective of whether it succeeds or fails, authentication proceeds to the next login module in the list. If it is the only login module, the administrator is successfully logged in.
Requisite. The login module is required to succeed. If it succeeds, authentication proceeds to the next login module in the list. If it fails, authentication does not proceed.
Sufficient. The login module is not required to succeed. If it does succeed, authentication does not proceed to the next login module, and the administrator is successfully logged in. If it fails, authentication continues to the next login module in the list.
Optional. The login module is not required to succeed. Irrespective of whether it succeeds or fails, authentication continues to the next login module in the list.
Login search attributes. (LDAP only.) Specify an ordered list of LDAP user attribute names to be used when attempting to bind (log in) to the associated LDAP server. Each of the LDAP user attributes specified, along with the user’s specified login name, is used (in order) to search for a matching LDAP user. This allows a user to log in to Identity Manager by using an LDAP cn or email address (when Identity Manager is configured for pass-through to LDAP).
For example, if you specify the following and the user attempts to log in as gwilson, then the LDAP resource will first attempt to find an LDAP user where cn=gwilson.
cn
If that succeeds, then the bind is attempted with the password specified by the user. If it does not succeed, then the LDAP resource will search for an LDAP user where mail=gwilson. If that also fails, then login fails.
If you do not specify a value, then the default LDAP search attributes are:
uid
cn
Login correlation rule. Select a login correlation rule to be used to map the login information provided by the user to an Identity Manager user. This rule is used to search for an Identity Manager user by using the logic specified in the rule. The rule must return a list of one or more AttributeConditions that will be used to search for an Identity Manager user that matches. The rule you select must have the LoginCorrelationRule authType. For a description of the steps Identity Manager takes to map an authenticated user ID to an Identity Manager user, see Example 12–2.
New user name rule. Select a new user name rule to be used when automatically creating new Identity Manager users as part of login.
Click Save to save a login module. Once it is saved, you can position the module relative to all other modules in the login module group.
If Identity Manager login is configured to authenticate to more than one system, an account’s user ID and password should be the same across all systems that are targets of Identity Manager authentication.
If the user ID and password combinations differ, login will fail on each system whose user ID and password do not match the user ID and password entered on the Identity Manager User Login form.
Some of these systems may have a lockout policy enforcing the number of failed login attempts before an account is locked. For these systems, user accounts are eventually locked, even though the user’s login through Identity Manager continues to succeed.
Example 12–2 contains pseudocode that describes the steps Identity Manager takes to map authenticated user IDs to Identity Manager users.
if an existing IDM user’s ID is the same as the specified user ID if that IDM user has a linked resource whose resource name matches the resource that was authenticated and whose accountId matches the resource accountId returned by successful authentication (e.g. dn), then we have found the right IDM user otherwise if there is a LoginCorrelationRule associated with the configured login module evaluate it to see if it maps the login credentials to a single IDM user otherwise login fails otherwise login fails if the specified userID does not match an existing IDM user’s ID try to find an IDM user that has a linked resource whose resource name matches the resource accountID returned by successful authentication if found, then we have found the right IDM user otherwise if there is a LoginCorrelationRule associated with the configured login module evaluate it to see if it maps the login credentials to a single IDM user otherwise login fails otherwise login fails |
In Example 12–2, the system will try to find a matching Identity Manager user using the user’s linked resources (resource information). If the resource information approach fails, however, and a loginCorrelationRule is configured, the system will try to find a matching user using the loginCorrelationRule.
If you have multiple resources that are logically the same (for example, multiple Active Directory domain servers that share a trust relationship), or if you have multiple resources that all reside on the same physical host, then you can specify that these resources are common resources.
You should declare common resources so that Identity Manager knows that it should only try and authenticate to a group of resources one time. Otherwise, if a user types a wrong password, Identity Manager will try the same password against each resource. This can lead to the user’s account being locked out due to multiple login failures, even though the user only typed the wrong password one time.
With common resources, a user can authenticate to one common resource, and Identity Manager will automatically try and map the user to the remaining resources in the common resources group. For example, an Identity Manager user account may be linked to a resource account for resource AD-1. The login module group, however, may define that users must authenticate to resource AD-2.
If AD-1 and AD-2 are defined as common resources (in this case, in the same trusted domain), then if the user successfully authenticates to AD-2, Identity Manager can also map the user to AD-1 by finding the same user accountId on resource AD-1.
All resources listed in a common resources group must also be included in the Login Module definition. If a complete list of common resources does not also appear in the Login Module definition, then the common resources functionality will not work correctly.
Common resources can be defined in the System Configuration object (Editing Identity Manager Configuration Objects) using the following format.
<Attribute name=’common resources’> <Attribute name=’Common Resource Group Name’> <List> <String>Common Resource Name</String> <String>Common Resource Name</String> </List </Attribute> </Attribute> |
Use the following information and procedures to configure X509 Certificate Authentication for Identity Manager.
To support X509 certificate-based authentication in Identity Manager, ensure that two-way (client and server) SSL authentication is configured properly. From the client perspective, this means that an X509-compliant user certificate should have been imported into the browser (or be available through a smart card reader), and that the trusted certificate used to sign the user certificate should be imported into the Web application server’s keystore of trusted certificates.
Also, the client certificate used must be enabled for client authentication.
Using Internet Explorer, select Tools, and then select Internet Options.
Select the Content tab.
In the Certificates area, click Certificates.
Select the client certificate, and then click Advanced.
In the Certificate Purposes area, verify that the Client Authentication option is selected.
Log in to the Administrator Interface as Configurator (or with equivalent permissions).
Select Configure, and then select Login to display the Login page.
Click Manage Login Module Groups to displays the Login Module Groups page.
Select a login module group from the list.
Select Identity Manager X509 Certificate Login Module from the Assign Login Module list. Identity Manager displays the Modify Login Module page.
Set the login success requirement.
The following values are acceptable:
Required. The login module is required to succeed. Irrespective of whether it succeeds or fails, authentication proceeds to the next login module in the list. If it is the only login module, the administrator is successfully logged in.
Requisite. The login module is required to succeed. If it succeeds, authentication proceeds to the next login module in the list. If it fails, authentication does not proceed.
Sufficient. The login module is not required to succeed. If it does succeed, authentication does not proceed to the next login module, and the administrator is successfully logged in. If it fails, authentication continues to the next login module in the list.
Optional. The login module is not required to succeed. Irrespective of whether it succeeds or fails, authentication continues to the next login module in the list.
Select a login correlation rule. This could be a built-in rule or a custom correlation rule. (See the following section for information about creating custom correlation rules.)
Click Save to return to the Modify Login Module Group page.
Optionally, reorder the login modules (if more than one login module is assigned to the login module group, and then click Save.
Assign the login module group to a login application if it is not yet assigned. From the Login Module Groups page, click Return to Login Applications, and then select a login application. After assigning a login module group to the application, click Save.
If the allowLoginWithNoPreexistingUser option is set to a value of true in the waveset.properties file, then when configuring the Identity Manager X509 Certificate Login Module, you are prompted to select a New User Name Rule. This rule is used to determine how to name new users created when one is not found by the associated Login Correlation Rule. The New User Name Rule has the same available input arguments as the Login Correlation Rule. It returns a single string, which is the user name used to create the new Identity Manager user account. A sample new user name rule is included in idm/sample/rules, named NewUserNameRules.xml.
A Login Correlation Rule is used by the Identity Manager X509 Certificate Login Module to determine how to map the certificate data to the appropriate Identity Manager user. Identity Manager includes a built-in correlation rule, named Correlate via X509 Certificate subjectDN.
You can also add your own correlation rules. Refer to LoginCorrelationRules.xml, which is located in the idm/sample/rules directory, as an example.
Each correlation rule must follow these guidelines:
Its authType attribute must be set to LoginCorrelationRule
It is expected to return an instance of a list of AttributeConditions to be used by the login module to find the associated Identity Manager user. For example, the login correlation rule might return an AttributeCondition that searches for the associated Identity Manager user by email address.
Arguments passed to login correlation rules are:
Standard X509 certificate fields (such as subjectDN, issuerDN, and valid dates)
Critical and noncritical extension properties
The naming convention for certificate arguments passed to the login correlation rule is
cert.field name.subfield name
Example argument names that are available to the rule include:
cert.subjectDN
cert.issuerDN
cert.notValidAfter
cert.notValidBefore
cert.serialNumber
The login correlation rule, using the passed-in arguments, returns a list of one or more AttributeConditions. These are used by the Identity Manager X509 Certificate Login Module to find the associated Identity Manager user.
A sample login correlation rule is included in idm/sample/rules, named LoginCorrelationRules.xml.
After creating a custom correlation rule, you must import it into Identity Manager. From the Administrator Interface, select Configure, and then select Import Exchange File to use the file import facility.
To test the SSL connection, go to the configured application interface’s URL using SSL (for example, https://idm007:7002/idm/user/login.jsp). You are notified that you are entering a secure site, and then prompted to specify which personal certificate to send to the Web server.
Report any problems authenticating using X509 certificates as error messages on the login form.
For more complete diagnostics, enable trace on the Identity Manager server for these classes and levels:
com.waveset.session.SessionFactory 1
com.waveset.security.authn.WSX509CertLoginModule 1
com.waveset.security.authn.LoginModule 1
If the client certificate attribute is named something other than javaxservlet.request.X509Certificate in the HTTP request, then you will receive a message that this attribute cannot be found in the HTTP request.
Enable trace for SessionFactory to see the complete list of HTTP attributes and determine the name of the X509 Certificate.
Use the Identity Manager debug facility (The Identity Manager Debug Page) to edit the LoginConfig object.
Change the name of the <AuthnProperty> in the <LoginConfigEntry> for the Identity Manager X509 Certificate Login Module to the correct name.
Save, and then retry.
You may also need to remove, and then re-add the Identity Manager X509 Certificate Login Module in the login application.
Cryptography is used to ensure the confidentiality and integrity of server data in memory and in the repository, as well as all data transmitted between the Identity Manager Server and Gateway.
The following sections provide more information about how cryptography is used and managed in the Identity Manager Server and Gateway, and addresses questions about server and gateway encryption keys.
The following table shows the types of data that are cryptographically protected in the Identity Manager product, including the ciphers used to protect each type of data.
Table 12–1 Cryptographically-Protected Data Types
Data Type |
RSAMD5 |
NIST Triple DES168-Bit Key (DESede/ECB/NoPadding) |
PKCS#5 Password-Based Crypto56-Bit Key (PBEwithMD5andDES) |
---|---|---|---|
Server encryption keys |
default |
configuration option |
|
Gateway encryption keys |
default |
configuration option1 |
|
Policy dictionary words |
yes | ||
User passwords |
yes | ||
User password history |
yes | ||
User answers |
yes | ||
Resource passwords |
yes | ||
Resource password history |
yes | ||
All payload between server and gateways |
yes |
Read the following sections for answers to frequently asked questions about server encryption key source, location, maintenance, and use.
Question:Where do server encryption keys come from?
Answer:Server encryption keys are symmetric, triple-DES 168-bit keys.
There are two types of keys supported by the server:
Default key. This key is compiled into the server code.
Randomly generated key. This key can be generated at initial server startup, or any time the security of the current key is in question.
Where are server encryption keys maintained?
Answer:Server encryption keys are objects maintained in the repository. There can be many data encryption keys in any given repository.
Question:How does the server know which key to use for decryption and re-encryption of encrypted data?
Answer:Each piece of encrypted data stored in the repository is prefixed by the ID of the server encryption key that was used to encrypt it. When an object containing encrypted data is read into memory, Identity Manager uses the server encryption key associated with the ID prefix on the encrypted data to decrypt, and then re-encrypt with the same key if the data changed.
Question:How do I update server encryption keys?
Answer:Identity Manager provides a task called Manage Server Encryption.
This task allows an authorized security administrator to perform several key management tasks, including:
Generating a new “current” server key
Re-encrypting existing objects, by type, containing encrypted data with the “current” server key
See Managing Server Encryption in this chapter for more information about how to use this task.
Question:What happens to existing encrypted data if the “current” server key is changed?
Answer:Nothing. Existing encrypted data will still be decrypted or re-encrypted with the key referenced by the ID prefix on the encrypted data. If a new server encryption key is generated and set to be the “current” key, any new data to be encrypted will use the new server key.
To avoid multi-key issues, as well as to maintain a higher level of data integrity, use the Manage Server Encryption task to re-encrypt all existing encrypted data with the “current” server encryption key.
Question:What happens when you import encrypted data for which an encryption key is not available?
Answer:If you import an object that contains encrypted data, but that data was encrypted with a key that is not in the repository into which it is being imported, then the data will be imported, but not decrypted.
Question:How are server keys protected?
Answer:If the server is not configured to use password-based encryption (PBE) - PKCS#5 encryption (set in the System Configuration object using the pbeEncrypt attribute or the Manage Server Encryption task), then the default key is used to encrypt the server keys. The default key is the same for all Identity Manager installations.
If the server is configured to use PBE encryption, then a PBE key is generated each time the server is started. The PBE key is generated by providing a password, generated from a server-specific secret, to the PBEwithMD5andDES cipher. The PBE key is maintained only in memory and never persisted. In addition, the PBE key is the same for all servers sharing a common repository.
To enable PBE encryption of server keys, the cipher PBEwithMD5andDES must be available. Identity Manager does not package this cipher by default, but it is a PKCS#5 standard that is available in many JCE providers implementations, such as those provided by Sun and IBM.
Question:Can I export the server keys for safe external storage?
Answer:Yes. If the server keys are PBE encrypted, then before they are exported, they will be decrypted and re-encrypted with the default key. This allows them to be imported to the same or another server at a later date, independent of the local server PBE key. If the server keys are encrypted with the default key, then no preprocessing is done before they are exported.
When they are imported into a server, if the server is configured for PBE keys, the keys will be decrypted and then re-encrypted with the local server’s PBE key, if that server is configured for PBE key encryption.
Question:What data is encrypted between the server and gateway?
Answer:All data (payload) transmitted between the server and gateway is triple-DES encrypted with a randomly generated, per server-gateway session symmetric 168 bit key.
Read the following sections for answers to frequently asked questions about gateway source, storage, distribution, and protection.
Question:Where do the gateway keys come from to encrypt or decrypt data?
Answer:Each time an Identity Manager Server connects to a gateway, the initial handshake will generate a new random 168-bit, triple-DES session key. This key will be used to encrypt or decrypt all subsequent data transmitted between that server and that gateway. There is a unique session key generated for each server/gateway pair.
Question:How are gateway keys distributed to the gateways?
Answer:Session keys are randomly generated by the server and then securely exchanged between server and gateway by encrypting them with the shared secret master key as part of the initial server-to-gateway handshake.
At initial handshake time, the server queries the gateway to determine which mode it supports. The gateway can operate in two modes
Default mode. Initial server-to-gateway protocol handshake is encrypted with the default 168–bit triple-DES key, which is compiled into the server code.
Secure mode. A per shared repository, random, 168-bit key, triple-DES gateway key is generated and communicated from the server to the gateway as part of the initial handshake protocol. This gateway key is stored in the server repository like other encryption keys, and also stored by the gateway in its local registry.
When in secure mode and a server contacts a gateway, the server encrypts test data with the gateway key and sends it to the gateway. The gateway then attempts to decrypt the test data, add some gateway unique data to the test data, re-encrypt both, and send the data back to the server. If the server can successfully decrypt the test data and the gateway unique data, the server then generates the server-gateway unique session key, encrypts it with the gateway key and sends it to the gateway. Upon receipt, the gateway decrypts the session key and retains it for use during the life of the server-to-gateway session. If the server cannot successfully decrypt the test data and gateway unique data, the server encrypts the gateway key using the default key and sends it to the gateway. The gateway decrypts the gateway key using its compiled in default key and stores the gateway key in its registry. The server then encrypts the server-gateway unique session key with the gateway key and sends it to the gateway for use during the life of the server-to-gateway session.
From that point forward, the gateway will only accept requests from servers that have encrypted the session key with its gateway key. On startup, the gateway checks the registry for a key. If a key exists, the gateway will use that key. If there is no key, the gateway uses the default key. Once the gateway has a key set in the registry, the gateway no longer allows sessions to be established using the default key, which prevents someone from setting up a rogue server and establishing a connection to a gateway.
Can I update the gateway keys used to encrypt or decrypt the server-to-gateway payload?
Answer:Identity Manager provides a task called Manage Server Encryption that allows an authorized security administrator to do several key management tasks, including generate a new “current” gateway key and update all gateways with the “current” gateway key. This is the key that is used to encrypt the per-session key used to protect all payload transmitted between server and gateway. The newly generated gateway key will be encrypted with either the default key or PBE key, depending on the value of the pbeEncrypt attribute in the System Configuration (Editing Identity Manager Configuration Objects).
Question:Where are the gateway keys stored on the server, on the gateway?
Answer:On the server, the gateway key is stored in the repository just like server keys. On the gateway, the gateway key is stored in a local registry key.
Question:How are gateway keys protected?
Answer:The gateway key is protected the same way server keys are. If the server is configured to use PBE encryption, the gateway key will be encrypted with a PBE generated key. If the option is false, it will be encrypted with the default key. See Frequently Asked Questions about Server Encryption Keys for more information.
Question:Can I export the gateway key for safe external storage?
Answer:The gateway key can be exported using the Manage Server Encryption task, just as with server keys. See Frequently Asked Questions about Server Encryption Keys for more information.
Question:How are server and gateway keys destroyed?
Answer:Server and gateway keys are destroyed by deleting them from the server repository. Note that a key should not be deleted as long as any server data is still encrypted with that key or any gateway is still relying on that key. Use the Manage Server Encryption task to re-encrypt all server data with the current server key and to synchronize the current gateway key to all gateways to ensure no old keys are still being used before they are deleted.
The Identity Manager server encryption feature allows you to create new 3DES server encryption keys and encrypt these keys by using 3DES, PKCS#5, or AES (Advanced Encryption Standard) encryption. Only users with Security Administrator capabilities can run the Manage Server Encryption task, which is configured from the Manage Server Encryption page.
To open the Manage Server Encryption page,
Select Server Tasks > Run Tasks from the menu bar.
When the Available Tasks page displays, click Manage Server Encryption to open the Manage Server Encryption page.
Use this page to configure server and object encryption, gateway keys, back-up options, and execution mode.
Enter a Task Name.
This field defaults to Manage Server Encryption. You can enter a different task name if you do not want to use the default setting.
Choose one or more of the following options.
As you make a selection, .
Manage Server Encryption. Choose this option to configure server encryption.
The following additional options display:
Encryption of server encryption keys. You must specify a method for encrypting server encryption keys. Encryption types can include Triple DES, PKCS#5 (DES), or PKCS#5 (AES)
Only those encryption types that are instantiable on your system will be displayed on this page. For example, if your system does not support PKCS#5 (AES), only Triple DES and PKCS#5 (DES) are displayed.
PKCS#5 (AES) requires that you download and configure the "Unlimited Strength Jurisdiction Policy Files" for the JVM running Identity Manager. Refer to your Java vendor's documentation for details..
Also, PKCS#5 (AES) requires that you install and configure the Bouncy Castle JCE provider jar file as a JCE provider for the JVM running Identity Manager. This jar file is packaged in the Identity Manager install image and can be found in the wshome/WEB-INF/lib directory. Two jar files are provided; bcprov-jdk15-137.jar and bcprov-jdk16-137.jar for use with corresponding versions of Java. Refer to your Java vendor's documentation and the Bouncy Castle documentation for more details.
Generate new server encryption key and set as current server encryption key. Select to generate a new server encryption key. Each piece of encrypted data generated after you make this selection is encrypted with this key. Generating a new server encryption key does not affect the key applied to existing encrypted data.
Generate new secure random PBE password. Select this option to generate a new password, based on a server-specific secret, each time the server is started. If you do not select this option, or if your server is not configured to use password-based encryption, then Identity Manager will use the default key to encrypt the server keys.
Manage Object Encryption. Choose this option to specify which object types should be re-encrypted and which encryption method to use.
Encryption of object types. Choose one of the displayed encryption types, which can include Triple DES (default), AES 256–bit key, AES, 192–bit key, or AES 128–bit key.
AES using 192– or 256–bit keys requires that you download and configure the “Unlimited Strength Jurisdiction Policy Files” for the JVM running Identity Manager. Refer to your Java vendor's documentation for more details.
Only those encryption types that are instantiable on your system will be displayed on this page. For example, if your system does not support AES 192– or 256–bit keys using the “Unlimited Strength Jurisdiction Policy Files”, only Triple DES and AES 128–bit key options are displayed.
Select object types to re-encrypt with current server encryption key. Choose one or more Identity Manager object types listed in the table.
Manage Gateway Keys. Choose this option to specify gateway encryption.
The following options display:
Select gateway key option. Choose one of the following options:
Generate a new key and synchronize all gateways. Choose this option when initially enabling a secure gateway environment. This option generates a new gateway key and communicates that key to all gateways.
Synchronize all gateways with current gateway key. Select to synchronize any new gateways, or gateways that have not communicated the new gateway key. Select this option if you had a gateway that was down when all gateways were synchronized with the current gateway key, or when you want to force a key update for a new gateway.
Gateway key type. Choose one of the displayed key types, which can include Triple DES, AES 256–bit key, AES, 192–bit key, or AES 128–bit key.
AES using 192– or 256–bit keys requires that you download and configure the “Unlimited Strength Jurisdiction Policy Files” for the JVM running Identity Manager. Refer to your Java vendor's documentation for more details.
Only those encryption types that are instantiable on your system will be displayed on this page. For example, if your system does not support AES 192– or 256–bit keys using the “Unlimited Strength Jurisdiction Policy Files”, only Triple DES and AES 128–bit key options are displayed.
Export server encryption keys for backup. Choose this option to export existing server encryption keys to an XML-formatted file. When you select this option, Identity Manager displays an additional field for you to specify a path and file name to export the keys.
Select this option if you are using PKCS#5 encryption and chose to generate and set a new server encryption key. In addition, you should store the exported keys on removable media and in a secure location (not on a network).
Choose the Execution Mode.
You can run this task in the foreground or background (default setting).
If you choose to re-encrypt one or more object types with a newly generated key, that task can take some time and is best run in the background.
When you are finished configuring the options on this page, click Launch.
You typically use permissions specified in an AdminGroup capability to grant access to an Identity Manager objectType such as a Configuration, Rule, or TaskDefinition. However, granting access to all objects of an Identity Manager objectType within one or more controlled organizations is sometimes still too broad.
Using authorization types (AuthType) allows you to further scope or restrict this access to a subset of objects for a given Identity Manager objectType. For example, you might not want to give your users access to all rules within their scope of control when populating rules to select from in a user form.
To define a new authorization type, edit the AuthorizationTypes configuration object in the Identity Manager repository and add a new <AuthType> element.
This element requires two properties:
The name of the new authorization type
The existing authorization type or objectType the new element extends or scopes
For example, if you want to add a new Rule authorization type, called Marketing Rule, that extends Rule, you would define the following:
<AuthType name=’Marketing Rule’ extends=’Rule’/>
Next, to enable the authorization type to be used, you must reference that authorization type in two places.
Within a custom AdminGroup capability that grants one or more rights to the new authorization type
Within the objects that should be of this type
Following are examples of both references. The first example shows an AdminGroup capability definition granting access to Marketing Rules.
<AdminGroup name=’Marketing Admin’> <Permissions> <Permission type=’Marketing Rule’ rights=’View,List,Connect,Disconnect/> </Permissions> <AdminGroups> <ObjectRef type=’AdminGroup’ id=’#ID#Account Administrator’/> </AdminGroups> </AdminGroup> |
The next example shows a Rule definition that enables users to access the object because they have been granted access to Rule or Marketing Rule.
<Rule name=’Competitive Analysis Info’ authType=’Marketing Rule’> ... </Rule> |
Any user granted rights to a parent authorization type, or to a static type that an authorization type extends, will have the same rights on all child authorization types. So, using the preceding example, any user granted rights to Rule will also have the same rights to Marketing Rule. The converse, however, is not true.
As an Identity Manager administrator, you can further reduce security risks to your protected accounts and data by following these recommendations, at setup time and after.
To reduce security risks during setup:
Access Identity Manager through a secure Web server using HTTPS.
Reset the passwords for the default Identity Manager administrator accounts (Administrator and Configurator). To further protect the security of these accounts, you can rename them.
Limit access to the Configurator account.
Limit administrators’ capability sets to only those actions needed for their job functions, and limit administrator capabilities by setting up organizational hierarchies.
Change the default password for the Identity Manager Index Repository.
Turn on auditing to track activities in the Identity Manager application.
Edit the permissions on files in the Identity Manager directory.
Customize workflows to insert approvals or other checkpoints.
Develop a recovery procedure to describe how to recover your Identity Manager environment in the event of emergency.
To reduce security risks during use:
Periodically change the passwords for the default Identity Manager administrator accounts (Administrator and Configurator).
Log out of Identity Manager when not actively using the system.
Set or know the default timeout period for an Identity Manager session. Session timeout values may differ, as they can be set independently for each login application.
If your application server is Servlet 2.2-compliant, the Identity Manager installation process sets the HTTP session timeout to a default value of 30 minutes. You can change this value by editing the property; however, you should set the value lower to increase security. Do not set the value higher than 30 minutes.