Internal User Properties

This topic describes various configuration tabs available within the properties. Every internal user has a set of extended user properties that can be set either when the user is first added to the system, or deferred until a later date. (During initial entry, only a minimal amount of user data is required, to facilitate rapid entry of many users.).
This topic describes various configuration tabs available within the properties. Every internal user has a set of extended user properties that can be set either when the user is first added to the system, or deferred until a later date. (During initial entry, only a minimal amount of user data is required, to facilitate rapid entry of many users.).
To access the properties for an internal user
  1. Do one of the following:
    • Create a new internal user, making sure to select the 
      Define Additional Properties
       check box.
    • Edit an existing internal user.
    • Locate the user by searching the identity provider.
    The User Properties dialog appears.
  2. Configure each tab within the properties as necessary. All information is optional. Refer to the appropriate section below for a complete description of each tab.
  3. Click [
    ] when done.
Configuring the [General] Tab
The [General] tab is used to enter additional basic information about the user, as well as to modify the password that was initially entered.
Indicates whether the account status is enabled or disabled. To enable the account, ensure this check box is selected. To disable an account, clear this check box.
If an account is expired, the check box is unavailable.
Account Status
Indicates the status of the account:
  • Active
    : The account is currently active and accessible to the user.
  • Locked
    : The user has attempted to log on incorrectly too many times. When the account is locked, an Administrator can unlock the account by clicking the [
    ] button that is displayed.
  • Inactive
    : The user has not logged in for longer than the inactivity period set in the Administrative User Account Properties dialog or the cluster property logon.inactivityPeriod. The Administrator can reactivate the account by clicking [
    ] button that is displayed.
Inactive or Locked users cannot log into the Policy Manager.
If the user account is expired or disabled, the last known state is displayed but the controls are unavailable. Authentication against Expired or Disabled accounts will also fail in message traffic. However, authentication against Active, Inactive, and Unlocked user accounts will be successful for message traffic.
In order to activate or unlock an account, the user must have the role "Administrator" or any custom role with Update permission for the entity type "Users". For more information, see Manage Roles.
First Name
Enter the user's first name. Note that this is different from the username, which cannot be modified.
Last Name
Enter the user's last name.
Enter the user's email address.
Click this button if you need to change the user password. Enter the new password, then retype to confirm.
For an internal user, resetting the password can both unlock a locked account and reactivate an inactive account.
When a password is reset by an administrator, or when a new account is created, some password rules are temporarily relaxed. The password created by the administrator must satisfy the password requirements; however, the following rules will be temporarily ignored
  • Character difference
  • Password Repeat Frequency
  • Allow One Password Change Per 24 Hours
To ensure that all password rules are met before users access the
API Gateway
, be sure to select [
Force password change for new user and reset
] in your password policy. For more information see Manage Password Policy.
Account Never Expires
Select this check box if the account is permanent. Clear this check box if the account should expire on a certain date.
Expires on
If the account will expire, enter the date or use the drop-down calendar control to select a date.
If an account has expired, this field appears red with the word "Expired" beside it. Credentials will not be accepted for an expired user.
Expired users in a service being consumed will be flagged in the Policy Validation Messages window and the Gateway Audit Events window.
Configuring the [Roles] Tab
The [Roles] tab is used to add or remove internal users from roles. At least one role must be set if the user will be logging in to the Policy Manager.
If no roles are assigned, the user's name and password will not be recognized on the login screen.
This tab is also used to assign roles to template users for Policy-Backed Identity Providers. A template user may have a default role, which is shown on this tab. This default is removed when any other role is added manually. For more information about template users, see Searching Identity Providers.
The table at the top lists the roles currently assigned to the user:
  • Name
    : The name of the role.
  • Type
    : "System" indicates a role that is either predefined or automatically generated (see Predefined Roles and Permissions). "Custom" indicates a role that has been defined by your organization (see Manage Roles).
  • Inherited
    : "No" means the user is assigned to the role directly; "Yes" means the user is a member of a group that has been assigned to that role.
The Role properties section at the bottom displays the complete description for the selected role.
To add the user to a role
  1. Click [
    ]. A list of eligible roles is displayed.
  2. Select the role(s) to which to add the user.
    To locate a role more easily, enter some text in the "Filter on name" box. This filters the roles list to display only those roles containing the filter text. Delete the filter text to restore the full list of roles.
  3. Click [
     to close the dialog.
To remove a user from a role
  1. Select the role(s) to be removed from the user. Hold down the [
    ] key to select multiple roles.
    You can only remove roles that are not inherited. To remove a user from an inherited role, remove the user from the group that has the role.
  2. Click [
(1) Users who need to log on to the Policy Manager must be assigned to at least one role. For more information, see Manage Roles. (2) If a role is both assigned and inherited, the interface will display "No" in the "Inherited" column and you are permitted to remove the role. Once removed, that role remains in the list, but the "Inherited" column changes to "Yes". 
Configuring the [Groups] Tab
The [Groups] tab is used to add or remove the user from internal groups.
  1. Click [
    ]. A list of groups appear.
  2. Select one or more groups that the user belongs to.  
    If the group you want isn't in the list, define it first using the steps under Create an Internal Group.
  3. Click [
    ]. The user is added to the group.
  4. If you need to remove a user from a group, select the group and then click [
Configuring the [Certificate] Tab
The [Certificate] tab is used to manage the certificate for the user.
  • To import a certificate for the user, click [
    ] and then complete the Add Certificate Wizard.
  • To export a certificate, click [
    ] and then specify a file name and location.
  • To revoke a certificate, click [
    ] and then click [
    ] to confirm. Revoking removes both the certificate and the user's password.
In the certificate that you import for a user, the CN value must match the username exactly to ensure proper authentication. For example, if the username is "suejones", then the CN value in the certificate must also be "suejones". If the CN was instead "", authentication fails.
Configuring the [SSH] Tab
The [SSH] tab is used to upload the user's SSH public key into his or her user record in the Require SSH Credentials Assertion (when the "Public Key" option is selected).
How authentication occurs:
  1. An API call arrives inbound to the Gateway using an SSH Transport.
  2. The client authenticates using public key cryptography, by proving possession of the private key that corresponds to the public key.
  3. The Require SSH Credentials Assertion gathers these credentials.
  4. An authentication assertion such as Authenticate Against an Identity Provider attempts to authenticate a user from these credentials.
  5. If you have configured the user’s [SSH] tab to contain the public key gathered in step 3, the authentication succeeds.
Either paste the public key into the box or click [
Load from file
] to insert the key from a text file. The key must be in the RSA or DSA in PEM PKCS8 format.
For more information about SSH processing, see Working with SCP/SFTP Messages.