IdP Security Configuration

Two Phases of Federated Login

As the service provider, IAM is responsible for configuration management in the authorization phase. If users misconfigure settings in the authorization phase, it may lead to a loss of control over the permission scope.

In other words, any reference to a "SAML assertion" below can be interpreted as an "OIDC ID token", and any reference to "attributes in the assertion" can be interpreted as "claims in the OIDC ID token". Separate configuration examples for the OIDC protocol will not be provided.

Common Issues and Best Practices for IAM IdP Security Configuration

• Issue 1: Overly Broad Identity Admission Configuration Allows Any IdP User to Log In to Huawei Cloud
  Assume that you have configured a SAML- or OIDC-based virtual user IdP by following the instructions in Identity Providers, created the ecs_readonly user group in IAM, and attached the ECS ReadOnlyAccess system policy to the user group. The identity conversion rules for the IAM IdP are as follows:

  [
      {
          "remote": [
              {
                  "type": "__NAMEID__"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "FederationUser"
                  }
              }
          ]
      },
      {
          "remote": [
              {
                  "any_one_of": [
                      "idp_ecs_readonly"
                  ],
                  "type": "Groups"
              }
          ],
          "local": [
              {
                  "group": {
                      "name": "ecs_readonly"
                  }
              }
          ]
      }
  ]

  The above identity conversion rules consist of two rules. The first is an identity admission rule, and the second is a permission granting rule. The meaning is as follows:

  1. After the SAML assertion signature is verified, as long as a NameID sub-element exists in the Subject element of the SAML assertion, the IdP user can be mapped to a Huawei Cloud virtual user named FederationUser.
  2. If a Groups attribute exists in the AttributeStatement element of the SAML assertion, and any one of its attribute values is idp_ecs_readonly, then the virtual user named FederationUser will have the permissions of the ecs_readonly user group in IAM.
  This identity conversion rule has the following two issues:

  1. It uses the generic type __NAMEID__ in the remote-side mapping.
  2. The first identity admission rule is extracted as a standalone rule, but no conditional operator is configured.

  Normally, the Subject element of a SAML assertion always carries a NameID sub-element. Since this rule does not have a conditional operator for validation, all users on the IdP side can log in to the of Huawei Cloud through the first rule. Even if a user does not belong to the idp_ecs_readonly user group on the IdP side, this only affects whether the user is granted the corresponding permissions after logging in to the of Huawei Cloud; it does not prevent the user from completing the login.

• Best Practice 1: Properly Configuring Identity Access Rules to Allow Only Target IdP Users to Log In to the of Huawei Cloud
  The correct approach is to combine the identity admission rule and the permission granting rule into a single rule, and then use a conditional operator to restrict identity admission:

  [
      {
          "remote": [
              {
                  "type": "FirstName"
              },
              {
                  "type": "LastName"
              },
              {
                  "any_one_of": [
                      "idp_ecs_readonly"
                  ],
                  "type": "Groups"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "{0} {1}"
                  }
              },
              {
                  "group": {
                      "name": "ecs_readonly"
                  }
              }
          ]
      }
  ]

  In the above identity conversion rule, no conditional operators are added to the FirstName and LastName types on the remote side because their values need to be passed to the placeholders in local.user.name. However, since the identity admission rule and the permission granting rule are combined into one, the entire identity conversion rule is controlled by the any_one_of conditional operator. The meaning of the expression is as follows:

  After the SAML assertion signature is verified, when a Groups attribute exists in the assertion and one of its attribute values is idp_ecs_readonly, if the FirstName and LastName attributes also exist in the assertion, the IdP user can be mapped to a Huawei Cloud virtual user whose name is ${FirstName} ${LastName}, and this virtual user will have the permissions of the ecs_readonly user group in IAM.

  In this way, only users in the idp_ecs_readonly user group on the IdP side can log in to Huawei Cloud, and other unrelated legitimate IdP users cannot log in to Huawei Cloud, even if they also have FirstName and LastName attributes.

  

  For the identity conversion rule in best practice 1, if any_one_of is set to an empty array, for example, "any_one_of": [], all logins are denied, regardless of whether the IdP user has been added to a user group on the IdP side.

• Issue 2: No Least-Privilege Enforcement, Allowing Any Logged-in User to Get Excessive Permissions

  [
      {
          "remote": [
              {
                  "type": "FirstName"
              },
              {
                  "type": "LastName"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "{0} {1}"
                  }
              },
              {
                  "group": {
                      "name": "admin"
                  }
              }
          ]
      }
  ]

  The preceding identity conversion rule builds on Issue 1 and introduces the problem of excessive permissions. The meaning is as follows:

  After the SAML assertion signature is verified, if the FirstName and LastName attributes exist in the assertion, the IdP user can be mapped to a Huawei Cloud virtual user whose name is ${FirstName} ${LastName}, and this virtual user will have the permissions of the admin user group in IAM.

  Generally, all users on the IdP side have the basic attributes FirstName and LastName that indicate their names. Therefore, the above rule is equivalent to granting all users on the IdP side all permissions to operate resources on of Huawei Cloud.

• Best Practice 2: Grouping by Job Function and Granting Least Privilege
  The correct approach is to split the permission granting rules: assign different users in the IdP to different IdP user groups based on their job functions, then map the IdP user groups to the corresponding IAM user groups, and finally grant least-privilege permissions based on the different IAM user groups. Assume that you have already created the required ecs_readonly and ecs_admin user groups in IAM and granted the ECS ReadOnlyAccess and ECS FullAccess system policies to them, respectively. An identity conversion rule for least-privilege permission granting is as follows:

  [
      {
          "remote": [
              {
                  "type": "FirstName"
              },
              {
                  "type": "LastName"
              },
              {
                  "any_one_of": [
                      "idp_ecs_readonly"
                  ],
                  "type": "Groups"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "{0} {1}"
                  }
              },
              {
                  "group": {
                      "name": "ecs_readonly"
                  }
              }
          ]
      },
      {
          "remote": [
              {
                  "type": "FirstName"
              },
              {
                  "type": "LastName"
              },
              {
                  "any_one_of": [
                      "idp_ecs_admin"
                  ],
                  "type": "Groups"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "{0} {1}"
                  }
              },
              {
                  "group": {
                      "name": "ecs_admin"
                  }
              }
          ]
      }
  ]

  In the identity conversion rule above, two rules are defined based on job functions: users with ECS read-only permissions are assigned to the idp_ecs_readonly user group, while ECS administrator users are assigned to the idp_ecs_admin user group. The meaning is as follows:

  1. After the SAML assertion signature is verified, when a Groups attribute exists in the assertion and one of its attribute values is idp_ecs_readonly, if the FirstName and LastName attributes also exist in the assertion, the IdP user can be mapped to a Huawei Cloud virtual user whose name is ${FirstName} ${LastName}, and this virtual user will have the permissions of the ecs_readonly user group in IAM.
  2. After the SAML assertion signature is verified, when a Groups attribute exists in the assertion and one of its attribute values is idp_ecs_admin, if the FirstName and LastName attributes also exist in the assertion, the IdP user can be mapped to a Huawei Cloud virtual user whose name is ${FirstName} ${LastName}, and this virtual user will have the permissions of the ecs_admin user group in IAM.

  In this way, least-privilege permission granting is achieved. Users in different IdP user groups obtain different permissions after federated login. When a new user needs to log in to the of Huawei Cloud, you only need to add the user to the corresponding user group in the IdP.

  

  When multi-valued attributes are used, if a user is added to both the idp_ecs_readonly and idp_ecs_admin user groups on the IdP side, the virtual user will be mapped to both the ecs_readonly and ecs_admin user groups in Huawei Cloud.

• Common Issue 3: Direct IdP-to-IAM Group Mapping Without Conditional Operators Causes Uncontrolled Identity Admission
  When identity conversion rules are used to map IdP user groups directly to IAM user groups, if the remote side only performs an existence check on the Groups type without using a conditional operator, the identity admission outcome depends on how the IdP handles the Groups attribute.

  [
      {
          "remote": [
              {
                  "type": "FirstName"
              },
              {
                  "type": "LastName"
              },
              {
                  "type": "Groups"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "{0} {1}"
                  }
              },
              {
                  "groups": "{2}"
              }
          ]
      }
  ]

  The above identity conversion rule means:

  After the SAML assertion signature is verified, if the FirstName, LastName, and Groups attributes all exist in the assertion, the IdP user can be mapped to a Huawei Cloud virtual user whose name is ${FirstName} ${LastName}. The Groups attribute values on the IdP side are directly used as IAM-side user group names for matching. Whether the virtual user actually has permissions depends on whether the IdP-side user groups actually exist in IAM.

  Note that if the IdP user is not added to any user group on the IdP, the identity admission result depends on how the IdP processes the Groups attribute.

  Table 3 IdP's processing behavior when an IdP user is not added to any user group

  IdP's Processing Behavior When an IdP User Is Not Added to Any User Group	Groups Attribute Status Identified by IAM	Identity Admission Result
  The assertion sent by the IdP does not contain the Groups attribute.	Attribute does not exist	Login failure
  The assertion sent by the IdP contains the Groups attribute but its value is empty.	Attribute exists but its value is an empty string.	Login success

  That is to say, if the IdP still sends a Groups attribute with an empty value when the user has not been added to any user group, this rule is equivalent to allowing all IdP users with FirstName and LastName to log in to the of Huawei Cloud. Although they will not have any user group permissions after login, the identity admission configuration is still too permissive.

• Best Practice 3: When Mapping IdP User Groups to IAM User Groups, Use Condition Operators to Ensure Controllable Identity Admission
  If you want to map an IdP user group to an IAM user group with the same name, use condition operators for identity admission control.

  [
      {
          "remote": [
              {
                  "type": "FirstName"
              },
              {
                  "type": "LastName"
              },
              {
                  "type": "Groups"
              },
              {
                  "any_one_of": [
                      "idp_ecs_readonly",
                      "idp_ecs_admin"
                  ],
                  "type": "Groups"
              }
          ],
          "local": [
              {
                  "user": {
                      "name": "{0} {1}"
                  }
              },
              {
                  "groups": "{2}"
              }
          ]
      }
  ]

  In the above identity conversion rule, there are two Groups types on the remote side. This is because the Groups type with any_one_of is used only for identity admission. It ensures that only users whose Groups attribute in the assertion contains idp_ecs_readonly or idp_ecs_admin can log in to the of Huawei Cloud. It cannot extract the value of {2}. Therefore, if you want to continue using {2} in local.groups to directly extract the IdP user group names from the assertion, you must add an additional Groups type without a conditional operator on the remote side. The overall meaning is as follows:

  After the SAML assertion signature is verified, when the Groups attribute in the assertion contains idp_ecs_readonly or idp_ecs_admin, if the FirstName and LastName attributes also exist in the assertion, the IdP user can be mapped to a Huawei Cloud virtual user whose name is ${FirstName} ${LastName}. The IdP-side Groups attribute values are directly used as IAM-side user group names for matching. Whether the virtual user actually has permissions still depends on whether the IdP-side user groups actually exist in IAM.

  In this way, even if the IdP sends a Groups attribute with an empty value when the user has not been added to any user group, the any_one_of conditional operator will fail validation and thus prevent the user from logging in to the of Huawei Cloud.

Precautions for Using IAM Identity Providers

• Note 1: For independent attributes with the same name in the AttributeStatement element of an assertion, the IAM identity conversion rule only takes the value of the last attribute.
  For example, for the identity conversion rule in Best Practice 3, if the AttributeStatement element in the IdP assertion is as follows:

  <saml:AttributeStatement>
      <saml:Attribute Name="Groups"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">idp_ecs_readonly</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="Groups"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">idp_other</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute FriendlyName="First Name"
                      Name="FirstName"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">FirstName</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute FriendlyName="Last Name"
                      Name="LastName"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">LastName</saml:AttributeValue>
      </saml:Attribute>
  </saml:AttributeStatement>

  Then, for the above assertion, the groups that IAM obtains in local is ["idp_other"], which does not satisfy the value in the any_one_of operator, so login will fail. The standard way to pass multiple user groups from the IdP is to use multi-valued attributes. An example of setting Groups as a multi-valued attribute in an IdP assertion is as follows:

  <saml:AttributeStatement>
      <saml:Attribute Name="Groups"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">idp_ecs_readonly</saml:AttributeValue>
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">idp_other</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute FriendlyName="First Name"
                      Name="FirstName"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">FirstName</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute FriendlyName="Last Name"
                      Name="LastName"
                      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                               xsi:type="xs:string">LastName</saml:AttributeValue>
      </saml:Attribute>
  </saml:AttributeStatement>

  For the above assertion, the groups that IAM obtains in local are ["idp_ecs_readonly", "idp_other"], which satisfy the values in the any_one_of operator, so the login succeeds.

  

  The above precaution stems from the fact that the XML structure of SAML allows Attribute elements with the same name to appear repeatedly within the AttributeStatement element. In OIDC-based virtual user SSO, however, OIDC ID tokens are in JSON format, and claim names are unique. Therefore, the issue of only the last value being taken from independent claims with the same name does not exist. To pass multiple user groups under OIDC, simply use a multi-valued claim in array form, for example, "Groups": ["idp_ecs_readonly", "idp_other"].