Focus

Common Services: Identity and Access

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 iam.federation_mapping.update and iam.federation_mapping.delete

Use one of the various ways to access Identity & Access. Only one way is shown here.
Select Identity & Access/Access ManagementIdentity Federations
Scroll or search to find your identity federation.
Select Edit Tenant Mapping for Authorization.
Select which tenants can map users to the identity federation users and Save.

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.
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 accessPolicies.
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: superuser@prn:1563214651:::: and view_only_admin@prn:1119006635::::. 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 accessPolicies array in the payload, no changes are made to the user's IDP-based access.

Delete an Identity Federation

Update Tenant Mapping for Authorization