Page Comparison

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

...

There are no fields within the IDSYS document that are specific to the PAM back-end identity management system. If you are using PAM, follow this process to implement your identity management:

1. Because the root user (uid=0) on this Content Gateway server cannot be used to authenticate to the Gateway, create another user (such as superuser@admindomain.example.com) on this server for this purpose. 

2. Copy and paste this example into your IDSYS document: /etc/caringo/cloudscaler/idsys.json.

   Code Block
   language xml
   {"pam": { "name" : "idsys-pam", "description": "PAM identity management configuration", "cookieName": "token", "tokenPath": "/.TOKEN/", "tokenAdmin": "superuser@admindomain.example.com" } }

   
   

3. Update the tokenAdmin to match your authentication user.

...

The IDSYS inheritance also works at the field level, meaning that tenant and storage domain IDSYS documents can choose to override specific fields. For example, if tokenAdmin is defined in the Root IDSYS and not in the tenant or domain IDSYS, its value will be inherited by the tenant and domain levels. Similarly, the Root IDSYS may define the LDAP adminDN and adminPassword and let the tenant and domain IDSYS documents 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 that serves a single company. The configuration in this scenario is that the Root IDSYS defines 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 will 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 that has business units each with their own identity management systems, has multiple user/group sources. The configuration in this scenario is that the Root IDSYS defines the cluster administrator users and groups and the Tenant IDSYS documents define the users and groups for each customer or business unit. The storage domains do not define an IDSYS so that they inherit the definition from the tenant and share the users and groups with the other storage domains owned by their tenant.
• Service Provider with Resellers
  • This is an extension of the previous scenario except that each tenant could be a reseller offering storage domains to separate, unrelated companies. In this case, each storage domain would define an IDSYS that would override 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 their tenant, and others do not.

...

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

If a principal (user/group) authenticates from the same IDSYS as the resource they are accessing, their name in your policies may remain unqualified (no @domain or +tenant suffix on principal names). 

If a principal authenticates from a different IDSYS from the one used by the resource, Gateway uses the default assignment of the x-owner-meta header value to fully qualify the principal (such as user@domain or user+tenant). Applications can also assign object ownership across domains, where the IDSYS of the storage domain differs from that of the user from another domain. There is no limit on the number of cross-domain relationships you can have, but all must be within the same Swarm cluster.

...