What is the nature and description of the request?

Do not require the name of the group attribute to map to an Organization or Team in the Gateway Authentication Mapping.

With the new Authentication Mapping in Gateway, you must configure a mapping for each Organization and Team in your IdP. This means the AAP System Admin must know what groups exist in the IdP and be alerted to changes to these groups, especially when a new group is added. 

Example IdP configuration:

For example, say your idP sends 2 attributes, memberOf and adminOf, each consisting of a list of groups that user belongs to, and user1@company.com has the following values:

• memberOf: Group1, Group2
• adminOf: Group3 

AAP 2.4 configuration:

In AAP 2.4, a system admin doesn't need to know what groups exist in the IdP. AAP dynamically creates the Organizations based on the attribute values for memberOf and adminOf.  The following maps a user as an Org Member for any groups they belong to in memberOf and maps a user as an Org Admin for any groups they belong to in adminOf. 

"SOCIAL_AUTH_SAML_ORGANIZATION_ATTR": {
  "remove": true,  
  "saml_attr": "memberOf",
  "remove_admins": true,
  "saml_admin_attr": "adminOf" 
}

So when user1@company.com logs into AAP, the following Organizations would be created (if they don't already exist) with Org roles assigned: 

• Group1: Organization member
• Group2: Organization member
• Group3: Organization admin

A new Group4 could be added tomorrow in the IdP, and nothing would need to change in the AAP configuration. If that new group exists in the user's memberOf or adminOf attribute, a new organization will be created automatically when they log in and they will be assigned a role.  

AAP 2.5 configuration:

In AAP 2.5, you can still use the same memberOf and adminOf attributes, but you will need to know the possible memberOf and adminOf values from your IdP.

For example, you need to create the following mapping to map a user in your IdP group, Group1, to an Organization Group1 in AAP.

{
  (...)
  "name": "Group1 member mapping",
  "authenticator": 3,
  "map_type": "organization",
  "role": "Organization Member",
  "organization": "Group1",
  "team": null,
  "revoke": false,
  "triggers": {
    "attributes": {
      "memberOf": {
        "equals": "Group1"
      },
      "join_condition": "or"
    }
  }
}

NOTE: This is for 1 mapping. There would need to be 3 mappings in total, one for each group in this example.

When user1@company.com is created, Organization Group1 is created, like in AAP 2.4. However, if Group4 is added to the IdP tomorrow, a new mapping in AAP will need to be created to account for it.

Why does the customer need this? (List the business requirements here)

With AAP 2.5 mapping, a system admin now needs to know about the IdP values being provided and needs to be alerted to changes in configurations. They will then need to update their mappings in AAP. This adds a layer of communication not needed before and can cause issues when that communication doesn't happen or if system admins aren't aware of this potential issue.

Also, it takes time to perform these mappings. With the current AAP 2.5 requirements, 3 mappings would need to be created compared to a single field in AAP 2.4.

How would you like to achieve this? (List the functional requirements here)

Allow for the following Authentication fields to be optional:

• Comparison
• Value
• Organization/Team

If left blank, then the value for the defined Attribute is used.

For example, the following mapping would map ANY values for memberOf to an Organization of the same name in AAP. 

{
  (...)
  "name": "Org Member Mapping",
  "authenticator": 3,
  "map_type": "organization",
  "role": "Organization Member",
  "organization": null,            <------ no organization is set
  "team": null,
  "revoke": false,
  "triggers": {
    "attributes": {
      "memberOf": {
        "equals": null     <--- no value for memberOf is being defined
      },
      "join_condition": "or"
    }
  }
}