Users must change their password when the password has expired.
-
The password must meet the following requirements:
- Must contain 6 to 32 characters.
- Must contain at least two types of the following characters: uppercase letters (A to Z), lowercase letters (a to z), digits (0 to 9), spaces, and special characters (~`!?,.:;-_'"(){}[]/<>@#$%^&*+|\=).
- Cannot be the username or the username spelled backwards. For example, if the username is A12345, the password cannot be A12345, a12345, 54321A, or 54321a.
- Cannot contain the user's mobile number or email address.
+
The password must meet the following requirements:
- Must contain 6 to 32 characters.
- Must contain at least two types of the following: uppercase letters, lowercase letters, digits, and special characters (~`!?,.:;-_'"(){}[]/<>@#$%^&*+|\= and spaces).
- Cannot be the username or the username spelled backwards. For example, if the username is A12345, the password cannot be A12345, a12345, 54321A, or 54321a.
- Cannot contain the user's mobile number or email address.
In the Minimum Password Age area, select Allow a password to be changed only after it is used for a specified time and set the minimum password age.Users can change their password only when the specified period has expired.
Click Save.
-
Set the ACL.- In the navigation pane, choose Account Settings > ACL.
- On the ACL page, enter the allowed IP address ranges or IPv4 CIDR blocks.
- IP Address Ranges: only allow users to access the system using IP addresses in specified ranges.
- IPv4 CIDR Blocks: only allow users of specified IPv4 CIDR blocks to access the system. For example: 10.10.10.10/32.
- - The ACL takes effect only for users under your account.
- You can click Restore Defaults to restore the allowed IP address ranges to the default value, 0.0.0.0-255.255.255.255, and to clear IPv4 CIDR Blocks.
- If both IP Address Ranges and IPv4 CIDR Blocks are set, users are allowed to access the system if their IP address meets the conditions specified by either of the two parameters.
+
- Set the ACL.
- In the navigation pane, choose Security Settings > ACL.
- On the ACL page, enter the allowed IP address ranges or IPv4 CIDR blocks.
- IP Address Ranges: only allow users to access the system using IP addresses in specified ranges.
- IPv4 CIDR Blocks: only allow users of specified IPv4 CIDR blocks to access the system. For example: 10.10.10.10/32.
+ - The ACL takes effect only for users under your account.
- You can click Restore Defaults to restore the allowed IP address ranges to the default value, 0.0.0.0-255.255.255.255, and to clear IPv4 CIDR Blocks.
- If both IP Address Ranges and IPv4 CIDR Blocks are set, users are allowed to access the system if their IP address meets the conditions specified by either of the two parameters.
- - Click Save.
+ - Click Save.
diff --git a/docs/iam/umn/en-us_topic_0059870089.html b/docs/iam/umn/en-us_topic_0059870089.html
index 7c016f34b..038713f04 100644
--- a/docs/iam/umn/en-us_topic_0059870089.html
+++ b/docs/iam/umn/en-us_topic_0059870089.html
@@ -8,6 +8,8 @@
- SAML-based Federated Identity Authentication
+- OpenID Connect–based Federated Identity Authentication
+
- Syntax of Identity Conversion Rules
diff --git a/docs/iam/umn/en-us_topic_0079496985.html b/docs/iam/umn/en-us_topic_0079496985.html
index ff5266f83..c931ba25c 100644
--- a/docs/iam/umn/en-us_topic_0079496985.html
+++ b/docs/iam/umn/en-us_topic_0079496985.html
@@ -2,11 +2,11 @@
Managing Users and Permissions
As a security administrator, you can grant permissions to a user group and add users to it. The users inherit the permissions of the user group and can access the cloud system based on assigned permissions.
-
- Create projects in a region to isolate resources.
Figure 1 Project isolating model
+- Create projects in a region to isolate resources.
Figure 1 Project isolating model
- - Plan user groups according to user responsibilities and grant the required permissions to the user groups.
Figure 2 User group authorization model
+ - Plan user groups according to user responsibilities and grant the required permissions to the user groups.
Figure 2 User group authorization model
- - Create users and add them to the corresponding user groups.
Figure 3 User authorization model
+ - Create users and add them to the corresponding user groups.
Figure 3 User authorization model
- Log in as the users and access the cloud system based on assigned permissions.
+
+
\ No newline at end of file
diff --git a/docs/iam/umn/en-us_topic_0079620340.html b/docs/iam/umn/en-us_topic_0079620340.html
index aaf52dab5..832b31ba8 100644
--- a/docs/iam/umn/en-us_topic_0079620340.html
+++ b/docs/iam/umn/en-us_topic_0079620340.html
@@ -78,8 +78,8 @@
]
}
]
-
In this example, the username of a federated user will be "the value of the first remote attribute+space+the value of the second remote attribute" in the cloud system, that is, FirstName LastName. The groups to which the user belongs are the value of the third remote attribute Groups.
-
If the following assertion is received, the username of the federated user will be John Smith in the cloud system and the user will belong to the admin and manager groups.
+
In this example, the username of a federated user will be "the value of the first remote attribute+space+the value of the second remote attribute" in the cloud system, that is, FirstName LastName. The groups to which the user belongs are the value of the third remote attribute Groups.
+
If the following assertion is received, the username of the federated user will be John Smith in the cloud system and the user will belong to the admin and manager groups.
{FirstName: John}
{LastName: Smith}
{Groups: [admin, manager]}
@@ -111,7 +111,7 @@
}
]
The username of the federated user in the cloud system is the value of the first remote attribute, that is, UserName. The federated user belongs to the admin group. This rule takes effect only for users who are members of the idp_admin group in the identity provider system.
-
If a federated user will belong to multiple user groups in the cloud system, the identity conversion rule can be configured as follows:
+
If a federated user will belong to multiple user groups in the cloud system, the identity conversion rule can be configured as follows:
[
{
"local": [
@@ -137,7 +137,7 @@
]
}
]
-
The username of the federated user in the cloud system is the value of the first remote attribute, that is, UserName. The federated user belongs to the admin and manager groups. This rule takes effect only for users who are members of the idp_admin group in the identity provider system.
+
The username of the federated user in the cloud system is the value of the first remote attribute, that is, UserName. The federated user belongs to the admin and manager groups. This rule takes effect only for users who are members of the idp_admin group in the identity provider system.
- The following assertion indicates that the federated user John Smith is a member of the idp_admin group. Therefore, the user can access the cloud system.
{UserName: John Smith}
{Groups: [idp_user, idp_admin, idp_agency]}
- The following assertion indicates that the federated user John Smith is not a member of the idp_admin group. Therefore, the rule does not take effect for the user and the user cannot access the cloud system.
{UserName: John Smith}
diff --git a/docs/iam/umn/en-us_topic_0079620341.html b/docs/iam/umn/en-us_topic_0079620341.html
index fc4a9110f..fbabc7c85 100644
--- a/docs/iam/umn/en-us_topic_0079620341.html
+++ b/docs/iam/umn/en-us_topic_0079620341.html
@@ -6,23 +6,23 @@
Without Federated Identity Authentication
- Complex user management
The enterprise administrator has to create users in both the enterprise management system and the cloud system.
- Complex user operations
Users have to use different accounts to log in to the enterprise management system and cloud system.
-Figure 2 User login model (1)
+Figure 2 User login model (1)
With Federated Identity Authentication
Figure 1 Permissions management model
