: Map a Tenant for Authorization Through Common Services

Map a Tenant for Authorization Through Common Services

Table of Contents

Map a Tenant for Authorization Through
Common Services

Learn how to map a tenant for authorization through the
Common Services
If you want to grant authorization to your users by passing the login information through your Security Assertion Markup Language (SAML) provider, you can map your identity federation to a tenant or tenant service group (TSG) hierarchy. By using the tenant mapping, you no longer have to add users and access directly through
Common Services
, but that option is still available.
After you add an identity federation and add an identity federation owner, the federation owner can map tenants for authorization. In addition to adding an admin as a federation owner, you must also give that admin a role that has permissions to assign and remove access policies on the given tenant, such as the following:
  • IAM Administrator
  • Multitenant IAM Administrator
  • Multitenant Superuser
  • Superuser
  • Custom role that includes
  1. Use one of the various ways to access
    Identity & Access
    . Only one way is shown here.
  2. Select
    Identity & Access/Access Management
    Identity Federations
  3. Scroll or search to find your identity federation.
  4. Select
    Edit Tenant Mapping for Authorization
  5. Select which tenants can map users to the identity federation users and
    Inheritance applies the same way as it does in access management. If you map a tenant at the top level of the hierarchy, the child tenants nested below it will inherit the mapping so that the parent can manage them.
    The identity federation owner can now manage the user access for all the selected tenant Service Groups.
  6. Go to your identity provider’s console to configure user access policies. The console details look similar to the following, but all providers are slightly different. You must name the attribute
    1. (Optional)
      Use a predefined role to assign a predefined set of permissions to a user. For details and syntax, see properties for predefined roles.
    2. (Optional)
      Use a custom role to assign a custom set of permissions to a user. For details and syntax, see properties for custom roles.
Example SAML Response
This format applies to new customers as of December 2022. For existing
Prisma SD-WAN
customers, refer to Single Sign On Access using SAML.
Your IDPs may pass IDP defined access policies through a SAML attribute as follows:
<saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user@example.com</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="accessPolicies" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">superuser@prn:1563214651::::</saml2:AttributeValue> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">view_only_admin@prn:1119006635::::</saml2:AttributeValue> </saml2:Attribute>
In this example, there are two IDP defined access policies for this user:
. For each IDP defined access policy returned, IAM will attempt to create access policies according to what is shown in the SAML, and remove any other IDP defined access policies that this user has.
If you don't send the
array in the payload, no changes are made to the user's IDP-based access.

Recommended For You