Map a Tenant for Authorization Through Common Services
Expand all | Collapse all
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
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
.
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.