Scoping constraint and email type other in VIP Authentication Hub

Products

• VIP Authentication Hub

Issue/Introduction

 

Defining a new authAZ role with t.users and t.groups and applied the below scoping constraint to it.

 

When login with a user with this role.

 

The user can be created, but the email type is missing and verified fields resulting in creating a user with no email verified, type other and thus the user never receives the reset password email.

 

Scoping constraint:

 

{

    "name": "API Users minima",

    "description": "privileges de test",

    "resource": "urn:res:iam:user",

    "data":

    [

{

    "attr": "*",

    //Declare No permission by default

    "priv": "-"

    

},

{

    "attr": "given_name",

    //Declare RW on App attrs

    "priv": "rw" 

},

{ "attr": "user_loginId","priv": "rw" }, 

{ "attr": "family_name", "priv": "rw" }, 

{ "attr": "email", "priv": "rw" }, 

{ "attr": "verified", "priv": "rw" }

    ] 

}

 

Adding a new user in the UI, the user is created with email type other and verified no thus not receiving the password reset email.

 

Resolution

While defining the scoping constraints, the type, primary and verified attribute names should be given as below in the payload:

  {
      "attr": "email",
      "priv": "rw"
  },
  {
      "attr": "email.primary",
      "priv": "rw"
  },
  {
      "attr": "email.type",
      "priv": "rw"
  },
  {
      "attr": "email_verified",
      "priv": "rw"
  }

I.e. the primary, type and verified should all be granted the 'rw' constraint. Also, please note the correct author names.

To see all the possible user attributes, bring up the Internal Identity Store under Settings --> Identity Stores.

What is displayed in the Internal Identity Store settings are the logical attribute definitions.

The names shown here must match the names used in the Scoping Constraint (actually all AH policies referencing user attributes must use the logical names).

Generally there is a direct mapping of logical (name) to SCIM (SCIM URI).

In this case "email" maps to SCIM "email.value".

So as stated, fully declare the email subfields permissions when using wild cards with no access as the default in the policy.