Page Comparison

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

...

When a user authenticates to the Gateway using HTTP Basic authentication (that is, not token-based authentication and not S3 HMAC), the user's password is stored in the normal field for LDAP or PAM and it may be hashed in whatever formats are supported by the system. For LDAP, this field is normally userPassword; for PAM with the traditional Unix authentication mechanism, it is the second field in the /etc/shadow file.

...

{"ldap": {
	"name" : "idsys-ldap",
	"description": "LDAP identity management configuration",

	"protocol" : "ldaps",
	"ldaphost": ["ldap.example.com", "ldap-sec.example.com"],
	"ldapport": 636,

	"adminDN": "uid=YOURUSERNAMEUSERNAME,ou=Users,dc=example,dc=com",
	"adminPassword": "YOURPASSWORDPASSWORD",

	"userBase": "ou=Users,dc=example,dc=com",
	"groupBase": "ou=Groups,dc=example,dc=com",

	"userFilter": "objectclass=account",
	"groupMemberUidAttr": "memberUid",

	"cookieName": "token",
	"tokenPath": "/.TOKEN/",
	"tokenAdmin": "superuser@admindomain.example.com"
} }

...

¹ The groupMemberUidAttr and groupMemberDNAttr parameters are mutually exclusive and only one must be defined in IDSYS.

² The s3SecretKeyAttr parameter is only needed when using S3 Protocol Personality with a user password stored in LDAP. It is not required when using token authentication exclusively.

The adminDN and adminPassword parameters define the credentials with which the Gateway binds to the LDAP system in order to perform queries and read records for users and groups. The adminDN entity within LDAP needs to have read level access (rscdx privileges) within the LDAP tree. It is not necessary to grant write or manage level access to Gateway.

• A user's name in an access control Policy document is the value of the LDAP attribute named by the uidAttribute parameter. By default this This is the uid attribute of a user's LDAP record by default .

• A group's name in an access control Policy document is the cn attribute for the group LDAP entity. The name of this attribute cannot be configured. A group's name may contain spaces and other non-alphanumeric characters.

...

The root IDSYS configuration is stored in the idsys.json file on the Gateway server's disk so it is always available and an administrator can always modify it. In other words, this This prevents locking oneself out of the storage cluster. Changes to the local file take effect without the need to restart the Gateway.

For See Defined ETC Documents for modifying a tenant or storage domain's sub-resource through the management API, see Defined ETC Documents.

For See SCSP Context Sub-resources for details on modifying a storage domain's sub-resource through the storage API, see SCSP Context Sub-resources.

The entire JSON document with all fields must be provided in the update request, even if only one field is being modified when updating an IDSYS sub-resource through the management API or the storage API.

...

The identity system is described by IDSYS documents can exist at the root, tenant, and storage domain within the system. The lowest level overrides the higher levels when IDSYS documents exist at multiple levels in the hierarchy. It inherits from a higher level when a lower level lacks an IDSYS.

...

For example, if only a Root IDSYS exists, all tenants and all storage domains inherit from the Root IDSYS if a Root IDSYS exists. There is 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. The storage domains inherit from the Tenant IDSYS.

The IDSYS inheritance also works at the field level. Tenant and storage domain IDSYS documents can choose to override specific fields. 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 Root IDSYS may define the LDAP adminDN and adminPassword and 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 verify 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:

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

...