Managing User Credentials

Learn how users can manage their own credentials and what administrators can do with various types of user credentials for other users.

This topic describes the basics of working with Oracle Cloud Infrastructure Identity and Access Management (IAM) user credentials. If you're not already familiar with the available credentials, see User Credentials.

Working with Console Passwords and API Keys

Each user automatically has the ability to change or reset their own identity domain password, as well as manage their own API keys. An administrator does not need to create a policy to give a user those abilities.

To manage credentials for users other than yourself, you must be in the Administrators group or some other group that has permission to work with the tenancy. Having permission to work with a compartment within the tenancy is not sufficient. For more information, see The Administrators Group, Policy, and Administrator Roles.

IAM administrators (or anyone with permission to the tenancy) can use either the Console or the API to manage all aspects of both types of credentials, for themselves and all other users. This includes creating an initial one-time password for a new user, resetting a password, uploading API keys, and deleting API keys.

Users who are not administrators can manage their own credentials. They can:

  • Change or reset their own password.
  • Upload an API key in the Console for their own use (and also delete their own API keys).

And with the API, users can:

  • Reset their own password with CreateOrResetUIPassword.
  • Upload an additional API key to the IAM service for their own use with UploadApiKey (and also delete their own API keys with DeleteApiKey). Remember that a user can't use the API to change or delete their own credentials until they themselves upload a key to the identity domain or an administrator uploads a key for that user by using the Console or the API.

A user can have a maximum of three API keys at a time.

Working with Auth Tokens

Note

"Auth tokens" were previously named "Swift passwords". Any Swift passwords you had created are now listed in the Console as auth tokens. You can continue to use the existing passwords.

Auth tokens are Oracle-generated token strings that you can use to authenticate with third-party APIs that do not support Oracle Cloud Infrastructure's signature-based authentication. Each user created in the IAM service automatically has the ability to create, update, and delete their own auth tokens in the Console or the API. An administrator does not need to create a policy to give a user those abilities. Administrators (or anyone with permission to the tenancy) also have the ability to manage auth tokens for other users.

Note that you cannot change your auth token to a string of your own choice. The token is always an Oracle-generated string.

Auth tokens do not expire. Each user can have up to two auth tokens at a time. To get an auth token in the Console, see Creating an Auth Token.

Working with Customer Secret Keys

Note

"Customer Secret keys" were previously named "Amazon S3 Compatibility API keys". Any keys you had created are now listed in the Console as Customer Secret keys. You can continue to use the existing keys.

Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Oracle provides the Access Key that is associated with your Console user login. You or your administrator generates the Customer Secret key to pair with the Access Key.

Each user created in the IAM service automatically has the ability to create, update, and delete their own Customer Secret keys in the Console or the API. An administrator does not need to create a policy to give a user those abilities. Administrators (or anyone with permission to the tenancy) also have the ability to manage Customer Secret keys for other users.

Any user of the Amazon S3 Compatibility API with Object Storage needs permission to work with the service. If you're not sure if you have permission, contact your administrator. For information about policies, see How Policies Work. For basic policies that enable use of Object Storage, see Common Policies.

Customer Secret keys do not expire. Each user can have up to two Customer Secret keys at a time. To create keys using the Console, see Creating a Customer Secret Key.

Working With OAuth 2.0 Client Credentials

Note

OAuth 2.0 Client Credentials are not available in the United Kingdom Government Cloud (OC4).
OAuth 2.0 client credentials are required to interact programmatically with those services that use the OAuth 2.0 authorization protocol. The credentials enable you to obtain a secure token to access those service REST API endpoints. The allowed actions and endpoints granted by the token depend on the scopes (permissions) that you select when you generate the credentials. The services that use the OAuth 2.0 protocol are:
  • Oracle Analytics Cloud
  • Oracle Integration

An OAuth 2.0 access token is valid for 3600 seconds (1 hour).

To create the credentials, you need to know the service resource and scope. Typically, you can select these from a drop-down list. However, if the information is not available in the list, you can manually enter the resource and scope. The scope defines the allowed permissions for the token, so ensure to set the scope at the minimum required access level.

A user can create the credentials for themselves or an Administrator can create the credentials for another user. The lists of available resources and scopes display only those resources and permission levels that the user has been granted access to.

OAuth 2.0 Client Credential Limits

See IAM Object Limits to see how many OAuth 2.0 client credentials each user in your identity domain type can have.

Each OAuth 2.0 client credential can have up to 10 scopes.

Working with SMTP Credentials

Simple Mail Transfer Protocol (SMTP) credentials are needed in order to send email through the Email Delivery service. Each user is limited to a maximum of two SMTP credentials. If more than two are required, they must be generated on other existing users or additional users must be created.

Note

You cannot change your SMTP username or password to a string of your own choice. The credentials are always Oracle-generated strings.

Each user created in the IAM service automatically has the ability to create and delete their own SMTP credentials in the Console or the API. An administrator does not need to create a policy to give a user those abilities. Administrators (or anyone with permission to the tenancy) also have the ability to manage SMTP credentials for other users.

Tip

Although each user can create and delete their own credentials, it is a security best practice to create a new user and generate SMTP credentials on this user rather than generating SMTP credentials on your Console user that already has permissions assigned to it.

SMTP credentials do not expire. Each user can have up to two credentials at a time. To get SMTP credentials in the Console, see Generating SMTP Credentials.

For information about using the Email Delivery service, see Overview of the Email Delivery Service.

Working with IAM Database User Names and Passwords

Easier to use

Database end users can easily use IAM database passwords because they can continue to use a well-known authentication method to access the database. You can access database passwords that you manage through your OCI profile after you successfully authenticate to OCI.

Before users can access or manage their database password, IAM administrators can create an extra layer of protection by enforcing multifactor authentication using. For example, this can be a FIDO authenticator, or by pushing notifications through authenticator applications.

IAM Database Password Security

Using IAM database usernames and IAM database passwords to access databases improves security because they allow IAM administrators to centrally manage users and user access to database passwords within IAM instead of locally in each database. When a user leaves an organization, their IAM account is suspended and therefore, their access to all databases are automatically suspended. This method removes the possibility of unauthorized accounts being left on database servers after a user has left. For more information, see IAM Database Passwords. See the Oracle Security Guide, Chapter 7 for information about how IAM users authenticate and authorize to OCI databases.

IAM Database User Names

If your OCI IAM database username is longer than 128 bytes, you must set a different database username and a database password that is less than 128 bytes. IAM enforces the uniqueness of database usernames within a tenancy. The database user name is not case-sensitive and has the same allowable characters as an IAM user name (ASCII letters, numerals, hyphens, periods, underscores, +, and @)). This is more restrictive than local database usernames, which are governed by the character set of the database. See Database Object Names and Qualifiers for more information.

To create, change, and delete IAM database user names, see Working with IAM Database User Names.

Alternate IAM Database User Names

You can create an alternate IAM database user name that contains only letters and numbers, does not include special characters, and can be shorter than regular IAM database user names.

You can create an alternate IAM database user name:

  • If your user name is too long or hard to type
  • To make logging in easier with a user name that does not include special characters

IAM Database Password Specifications

The IAM database password complexity uses almost the same rules supported in IAM for OCI Console passwords (no double quotes ["] in IAM passwords). For details, see Creating an IAM database password.

Failed Login Lockouts

For information about failed logins, see IAM Database Password Lockouts.

Password Rollovers

Applications have a password in a wallet or other secure mechanism and in the database. When changing a database password, you also need to change the password in the application wallet. You normally do this during application downtime. However, having a second password allows you to change passwords without application downtime. Since both passwords are usable, the application admin can swap passwords in the application wallet files at their convenience, and can remove the old password from IAM later. This is independent of the database gradual password rollover status in the database. The database still reflects open status, that is, not open and in rollover.

Using the Console

Changing your Console Password

You're prompted to change your initial one-time password the first time you sign in to the Console. The following procedure is for changing your password again later.

Note

For Federated Users

If your company uses an identity provider (other than Oracle Identity Cloud Service) to manage user logins and passwords, you can't use the Console to update your password. You do that with your identity provider.

  1. Sign in to the Console by using your Oracle Cloud Infrastructure username and password.
  2. After you sign in, open the Profile menu (User menu icon), click My Profile, and then click Change password.

  3. Click Current password, and then enter the current password.
  4. Click New password, and then enter a new password.
  5. Click Confirm new password, and then enter the new password again.
  6. When you are finished and the password satisfies all password criteria, click Save.
Resetting Another User's Console Password

If you're an administrator, you can use the following procedure to reset a user's password. The procedure generates and sends a reset password email to the user. The email includes a link to the page where the user must change their password before they can sign in to the Console again.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Users.
  3. Click the user with the password that you want to reset.
  4. Click Reset password.

  5. To confirm, click Reset password.

    The user will receive an email prompting them to reset their password. If they don't change it within the period specified in the email, the link will expire and you'll need to reset the password for the user again.

Resetting Your Password If You Forgot It

If you have an email address in your user profile, you can use the Forgot Password link on the sign-in page to have a temporary password sent to you. If you don't have an email address in your user profile, you must ask an administrator to reset your password for you.

Unblocking a User

If you're an administrator, you can unblock a user who has tried 10 times in a row to sign in to the Console unsuccessfully. See Unlocking Users.

Adding an API Signing Key

You can use the Console to generate the private/public key pair for you. If you already have a key pair, you can choose to upload the public key. When you use the Console to add the key pair, the Console also generates a configuration file preview snippet for you.

The following procedures work for a regular user or an administrator. Administrators can manage API keys for either another user or themselves.

About the Configuration File Snippet

When you use the Console to add the API signing key pair, a configuration file preview snippet is generated with the following information:

  • user - the OCID of the user for whom the key pair is being added.
  • fingerprint - the fingerprint of the key that was just added.
  • tenancy - your tenancy's OCID.
  • region - the currently selected region in the Console.
  • key_file- the path to your downloaded private key file. You must update this value to the path on your file system where you saved the private key file.

If your configuration file already has a DEFAULT profile, you'll need to do one of the following:

  • Replace the existing profile and its contents.
  • Rename the existing profile.
  • Rename this profile to a different name after pasting it into the configuration file.

You can copy this snippet into your configuration file, to help you get started. If you don't already have a configuration file, see SDK and CLI Configuration File for details on how to create one.

Generating an API Signing Key Pair

Prerequisite: Before you generate a key pair, create the .oci directory in your home directory to store the credentials. See SDK and CLI Configuration File for more details.

  1. View the user's details:
    • If you're adding an API key for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator adding an API key for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click API keys.
  3. Click Add API key.
  4. In the dialog, click Generate API key pair.
  5. Click Download private key and save the key to your .oci directory. In most cases, you do not need to download the public key.

    Note: If your browser downloads the private key to a different directory, be sure to move it to your .oci directory.

  6. Click Add.

    The key is added and the Configuration file preview is displayed. The file snippet includes required parameters and values you'll need to create your configuration file. Copy and paste the configuration file snippet from the text box into your ~/.oci/config file. (If you have not yet created this file, see SDK and CLI Configuration File for details on how to create one.)

    After you paste the file contents, you'll need to update the key_file parameter to the location where you saved your private key file.

    If your configuration file already has a DEFAULT profile, you'll need to do one of the following:
    • Replace the existing profile and its contents.
    • Rename the existing profile.
    • Rename this profile to a different name after pasting it into the configuration file.
  7. Update the permissions on your downloaded private key file so that only you can view it:
    1. Go to the .oci directory where you placed the private key file.
    2. Use the command chmod go-rwx ~/.oci/<oci_api_keyfile>.pem to set the permissions on the file.
Uploading or Pasting an API Key

Prerequisite: You have generated a public RSA key in PEM format (minimum 2048 bits). The PEM format looks something like this:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoTFqF...
...
-----END PUBLIC KEY——
  1. View the user's details:
    • If you're adding an API key for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator adding an API key for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click API keys.
  3. Click Add API key.
  4. In the dialog, select Choose public key file to upload your file, or Paste a public key, if you prefer to paste it into the Public key text box.
  5. After you upload the file or paste the key into the text box, click Add.

    The key is added and the Configuration file preview is displayed. The file snippet includes required parameters and values you'll need to create your configuration file. Copy and paste the configuration file snippet from the text box into your ~/.oci/config file. (If you have not yet created this file, see SDK and CLI Configuration File for details on how to create one.)

    After you paste the file contents, you'll need to update the key_file parameter to the location where you saved your private key file.

    If your configuration file already has a DEFAULT profile, you'll need to do one of the following:

    • Replace the existing profile and its contents.
    • Rename the existing profile.
    • Rename this profile to a different name after pasting it into the configuration file.
Getting the Configuration File Snippet for an API Signing Key
The following procedure works for a regular user or an administrator.
  1. View the user's details:
    • If you're getting an API key configuration file snippet for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator getting an API key configuration file snippet for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click API keys. The list of API key fingerprints is displayed.
  3. Click the the Actions menu (three dots) for the fingerprint, and select View configuration file.

    The Configuration file preview is displayed. The file snippet includes required parameters and values you'll need to create your configuration file. Copy and paste the configuration file snippet from the text box into your ~/.oci/config file. (If you have not yet created this file, see SDK and CLI Configuration File for details on how to create one.) After you paste the file contents, you'll need to update the key_file parameter to the location where you saved your private key file.

    If your configuration file already has a DEFAULT profile, you'll need to do one of the following:
    • Replace the existing profile and its contents.
    • Rename the existing profile.
    • Rename this profile to a different name after pasting it into the configuration file.
Deleting an API Signing Key
The following procedure works for a regular user or an administrator. Administrators can delete an API key for either another user or themselves.
  1. View the user's details:
    • If you're deleting an API key for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator deleting an API key for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click API keys. The list of API key fingerprints is displayed.
  3. Select the check box for the API key you want to delete, and then click Delete.
  4. Confirm when prompted.
The API key is no longer valid for sending API requests.
Creating an Auth Token
  1. View the user's details:
    • If you're creating an auth token for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator creating an auth token for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click Auth tokens.
  3. Click Generate token.
  4. Enter a description that indicates what this token is for, for example, "Swift password token".
  5. Click Generate token.

    The new token string is displayed.

  6. Click Copy to copy the token string immediately, because you can't retrieve it again after closing the dialog box.
  7. When you are finished, click Close.

If you're an administrator creating an auth token for another user, you need to securely deliver it to the user by providing it verbally, printing it out, or sending it through a secure email service.

Deleting an Auth Token

The following procedure works for a regular user or an administrator. Administrators can delete an auth token for either another user or themselves.

  1. View the user's details:
    • If you're deleting an auth token for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator deleting an auth token for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click Auth tokens.
  3. Select the check box for the auth token you want to delete, and then click Delete.
  4. Confirm when prompted.

The auth token is no longer valid for accessing third-party APIs.

Creating a Customer Secret Key
  1. View the user's details:
    • If you're creating a customer secret key for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator creating a customer secret key for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click Customer secret keys.

    A customer secret key consists of an access key/secret key pair. Oracle automatically generates the access key when you or your administrator generates the secret key to create the customer secret key.

  3. Click Generate secret key.
  4. Click Name to enter a friendly name for the key, and then click Generate secret key.

    The generated secret key is displayed in the Generate secret key dialog box. At the same time, Oracle generates the access key that is paired with the secret key. The newly generated customer secret key is added to the list of Customer secret keys.

  5. Click Copy to copy the secret key immediately, because you can't retrieve the secret key again after closing the dialog box, for security reasons.

    If you're an administrator creating a secret key for another user, you need to securely deliver it to the user by providing it verbally, printing it out, or sending it through a secure email service.

  6. When you are finished, click Close.
  7. To show the access key, locate the secret key in the list of customer secret keys, and then click the access key in the Access key column. To copy the access key, while the access key is displayed, click Copy.
Deleting a Customer Secret Key

The following procedure works for a regular user or an administrator. Administrators can delete a customer secret key for either another user or themselves.

  1. View the user's details:
    • If you're deleting a customer secret key for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator deleting a customer secret key for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click Customer secret keys.
  3. Select the check box for the customer secret key you want to delete, and then click Delete.
  4. Confirm when prompted.

The customer secret key is no longer available to use with the Amazon S3 Compatibility API.

Creating OAuth 2.0 Client Credentials
Note

OAuth 2.0 client credentials are not available in the following realms :
  • the commercial realm (OC1)
  • the United Kingdom Government Cloud (OC4)
  1. View the user's details:
    • If you're creating an OAuth 2.0 client credential for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator creating an OAuth 2.0 client credential for another user:

      Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.

  2. Under Resources, click OAuth 2.0 client credentials.

  3. Click Generate OAuth 2.0 client credential.
  4. Click Name, and then enter a name for this credential.

  5. Click Title, and then enter a description for this credential.

  6. Add the URI for the OAuth 2.0 services that this credential will provide access to.

    To Select an audience-scope pair:
    1. In Audience, enter the URI for the OAuth 2.0 services.
    2. Next, select the Scope for this credential. Always select the minimum required privileges.
  7. To add more permissions to this credential, click + Another scope and follow the instructions in the previous step.
  8. Click Generate. The new secret string is generated.

    Click Copy to copy the token string immediately, because you can't retrieve it again after closing the dialog box.

    If you're an administrator creating OAuth 2.0 client credentials for another user, you need to securely deliver them to the user by providing them verbally, printing them out, or sending them through a secure email service.

  9. Click Close.

You will need the following information from the credential for the token request:

  • The generated secret
  • The OCID of the OAuth 2.0 client credential
  • The scope and audience (fully-qualified scope)
Adding Scopes to an Existing OAuth 2.0 Client Credential
  1. View the user's details:
    • If you're creating an OAuth 2.0 client credential for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator creating an OAuth 2.0 client credential for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click OAuth 2.0 client credentials.

  3. Click the name of the credential that you want to add scopes to.
  4. Click Add scopes.
  5. Add the URI for the OAuth 2.0 services that you want to add access to.

    To Select a resource-scope pair:
    1. Select the Select a resource-scope pair option.
    2. The Resource list displays the resources you have permission to view. Select the resource you want to add credentials for. After you select the resource, the Audience field is automatically populated.
    3. Next, select the Scope for this credential. Always select the minimum required privileges.
    To Enter fully qualified Scope:
    1. Select the Enter fully qualified scope option.
    2. Enter the Audience and Scope for this credential.
  6. To add more permissions to this credential, click + Another scope and follow the instructions in the previous step.
  7. Click Save.
Regenerating the OAuth 2.0 Client Credential Secret

IMPORTANT: When you regenerate the secret for a credential, requests made with the previous secret will be denied access to target scopes.

  1. View the user's details:
    • If you're creating an OAuth 2.0 client credential for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator creating an OAuth 2.0 client credential for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. On the left side of the page, click OAuth 2.0 client credentials.

  3. Click the name of the credential that you want to regenerate the secret for.
  4. Click Regenerate secret.
  5. Acknowledge the warning dialog and click Regenerate secret.
  6. Copy the token string immediately, because you can't retrieve it again after closing the dialog box.

    If you're an administrator creating OAuth 2.0 client credentials for another user, you need to securely deliver them to the user by providing them verbally, printing them out, or sending them through a secure email service.

  7. Click Close.

Ensure to update existing token requests with the new secret string.

Deleting an OAuth 2.0 Client Credential

The following procedure works for a regular user or an administrator. Administrators can delete an auth token for either another user or themselves.

  1. View the user's details:
    • If you're deleting an OAuth 2.0 Client Credential for yourself:

      Open the Profile menu (User menu icon) and click User Settings.

    • If you're an administrator deleting an auth token for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. On the left side of the page, click OAuth 2.0 Client Credentials.
  3. For the OAuth 2.0 Client Credential you want to delete, click Delete.
  4. Confirm when prompted.

The OAuth 2.0 Client Credential is no longer available to use.

Generating SMTP Credentials
  1. View the user's details:
    • If you're generating SMTP credentials for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator generating SMTP credentials for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click SMTP credentials.
  3. Click Generate credentials.

  4. Enter a Description of the SMTP credentials in the dialog box.
  5. Click Generate credentials. A user name and password are displayed.

    Click Copy to copy the password immediately, because you can't retrieve it again after closing the dialog box, for security reasons.

    If you're an administrator generating SMTP credentials for another user, you need to securely deliver them to the user by providing them verbally, printing them out, or sending them through a secure email service.

  6. When you are finished, click Close.
Deleting SMTP Credentials

The following procedure works for a regular user or an administrator. Administrators can delete SMTP credentials for either another user or themselves.

  1. View the user's details:
    • If you're deleting SMTP credentials for yourself:

      Open the Profile menu (User menu icon), and then click My Profile.

    • If you're an administrator deleting SMTP credentials for another user: Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Under Resources, click SMTP credentials.
  3. Select the check box for the SMTP credentials you want to delete, and then click Delete.
  4. Confirm when prompted.

The SMTP credentials are no longer available to use with the Email Delivery service.

To create an IAM Database Password

You can create an IAM database password to meet the Oracle Database password-creation guidelines. See Creating an IAM Database Password for the IAM database password specifications.

  1. Log in to the OCI IAM console.
  2. In the upper right corner of the window, click the profile icon to display your user profile page.
  3. In your user profile page, click your user name.
  4. Under Resources, click Database Passwords.
  5. In the Database Passwords section, click Create Database Password.

    The Create Database Password dialog box is displayed.

  6. Enter a description of the password.
  7. Note the password guidelines and restrictions listed on the page. See Creating an IAM database password for more information about password rules.
  8. Click Create Database Password.

    The dialog box closes and the description for which you have created a password is displayed in the Database Passwords section.

To change an IAM Database Password

To change your IAM database password, delete your current password and then create a new one. See To Delete an IAM Database Password and To create an IAM Database Password.

To delete an IAM database password

You can delete your own IAM database password.

  1. Log in to the OCI IAM console.
  2. In the upper right corner of the window, click the profile icon. This takes you directly to your user profile page.
  3. In your user profile page, click your user name.
  4. Under Resources, click Database Passwords.
  5. Your user name is displayed in the Database Passwords section.
  6. At the right end of the row with your user name in it, click the three-dot menu, and then click Delete.
To create an IAM Database User Name

To change your IAM database username:

  1. Log in to the OCI IAM console.
  2. Click Identity& Security.
  3. Under Identity, click Users.
  4. In the table of database users, click Create User.
  5. In the Name field, enter your database user name. Enter only letters, numerals, hyphens, periods, underscores, +, and @. You cannot use spaces in the name.
  6. In the Description field, optionally enter the name of the database that this user name is for or any other relevant information.
  7. Optionally click Advanced Options to show the Tags dialog box.
  8. In the Tag Namespace, Tag Key, and Value fields, enter a tag name
  9. Click Save Changes.
To change an IAM Database User Name

To change your IAM database username:

  1. Log in to the OCI IAM console.
  2. Click Identity& Security.
  3. Under Identity, click Users.
  4. In the table of database users, locate your database user name and left click it.

    The page for your user name is displayed.

  5. Click Edit User.
  6. In the Description field, edit your database user name and click Save Changes.
To delete an IAM Database User Name

To change your IAM database username:

  1. Log in to the OCI IAM console.
  2. Click Identity& Security.
  3. Under Identity, click Users.
  4. In the table of database users, locate your database user name and left click it.

    The page for your user name is displayed.

  5. At the right end of the row that contains your user name click the three-dot menu and then click Delete.