Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

IDSYS documents are JSON-formatted objects and are specific to the back-end identity management system: Active Directory, LDAP, and Linux PAM.

...

For example, if only a Root IDSYS exists, all tenants and all storage domains inherit from the Root IDSYS. In this case, there There is only one identity management system with one set of users and groups. Each tenant and the storage domains owned by them share an identity system separate from the Root IDSYS if the tenants each defines an IDSYS. In this second case, the The storage domains inherit from the Tenant IDSYS.

The IDSYS inheritance also works at the field level, meaning tenant and storage domain IDSYS documents can choose to override specific fields. For example, The value is inherited by the tenant and domain levels if tokenAdmin is defined in the Root IDSYS and not in the tenant or domain IDSYS, the value is inherited by the tenant and domain levels. Similarly, the . The Root IDSYS may define the LDAP adminDN and adminPassword and let allows the tenant and domain IDSYS documents to override the userBase and groupBase values.

  • Single Company

    • In this scenario, the company has one identity management system, there is one tenant per business unit, and each business unit has one or more storage domains. This scenario is likely with a private cloud serving a single company. The configuration in this scenario is the Root IDSYS defining the configuration of the identity management system and there are no IDSYS definitions for the tenants and storage domains. Therefore, the tenants and storage domains inherit from the Root IDSYS using a single source of users and groups.

  • Service Provider / Distributed Company

    • In this scenario, a storage MSP, or a large company with business units each with separate identity management systems and multiple user/group sources. The configuration in this scenario is the Root IDSYS defining the cluster administrator users and groups and the Tenant IDSYS documents defining the users and groups for each client or business unit. The storage domains do not define an IDSYS so they inherit the definition from the tenant and share the users and groups with the other storage domains owned by the tenant.

  • Service Provider with Resellers

    • This is an extension of the previous scenario except each tenant can be a reseller offering storage domains to separate, unrelated companies. In this case, each storage domain defined an IDSYS that overrides the Tenant IDSYS allowing a different set of users and groups for each storage domain. This scenario is not mutually exclusive with the previous one: a hybrid of the two is possible where some domains override the IDSYS of the tenant, and others do not.

...

It may be required to fully qualify the user and group principal names to ensure correct policy resolution. In access control policies and x-owner-meta headers, a "fully qualified" principal has a tenant name or storage domain appended directly to the name:

user
group

non-qualified

Principal from the same IDSYS scope as the content

user@domain
group@domain

fully qualified

Principal from a specific storage domain's IDSYS scope

user+tenant
group+tenant

fully qualified

Principal from a specific tenant's IDSYS scope

user@
group@

fully qualified

Principal from root scope only

...