In ISAM, it is called "secure domain". Everything you put in a new secure domain remains there and shielded from other domains. You can add users, groups, acl, pop, junction, … and server daemons (such as webseal, AuthZ) must be configured and inserted in corresponding secure domain. In other word, a particular webseal instance once configured against a secure domain can only serve users (and other resources) of that domain. You can run several webseal instances that are member of different domains on the same appliance. Also, once a user is created inside a particular secure domain, they cannot participate in other secure domains.

When implementing ISAM secure domain, you will want usually (as best practice advise) to ensure to lay them in different suffixes in your user registry to that they don't ever overlap if you intend to have the same userid created in different secure domains. And as far as SecUser objectclass are concerned, they are laid out in sub-ou containers such as the following assuming you create secure domain tenantA, tenantB, tenantC, …

• cn=users,secAuthority=tenantA,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantB,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantC,cn=Subdomains,secAuthority=default

You can have only one-level of subdomain. When you start creating secure domains, I encourage that you create one for every of you end-user communities (or tenants) so that in the end, the "Default" secure domain is nothing else than an empty top-level admin domain. This way, there can be no confusion about any assumed higher authority/permissions that resources in one sub-domain have other the others.

A use-case for this can sometime be to run several "tenants" inside the same appliance/infrastructure.

In our case, we did not implement ISAM Secure Domain for the purpose of delegated administration but rather this was for completely segmenting administratively each "tenant" into their owner "container".

Heads-up: When implementing ISAM secure domain, if you have any provisioning solution connected to your ISAM deployment (such as ISIM for instance), you will need to adjust those provisioning workflows to ensure to provision users in the right ISAM secure domain; ISIM provisioning adapter such as the "ISIM TAM Combo Adapter" support provisioning users in different domains although you might need to configured several instance of that service in ISIM.

We've never used ISAM Secure Domain for the sole purpose of delegated user administrations, however.

The sole components that can bridge between the numerous ISAM secure domain created (Default and other) is the ISAM Policy Server; there will not be a unique instance per domain. The ISAM Policy Server will create a new master authorization database for every new secure domain: this is how it is ensuring that all resources and their permissions are isolated by domain. For instance, an ACL created in tenantB will not be made available in tenantC for instance nor in the Default domain.

Hope this helps.

In ISAM, it is called "secure domain". Everything you put in a new secure domain remains there and shielded from other domains. You can add users, groups, acl, pop, junction, … and server daemons (such as webseal, AuthZ) must be configured and inserted in corresponding secure domain. In other word, a particular webseal instance once configured against a secure domain can only serve users (and other resources) of that domain. You can run several webseal instances that are member of different domains on the same appliance. Also, once a user is created inside a particular secure domain, they cannot participate in other secure domains.

When implementing ISAM secure domain, you will want usually (as best practice advise) to ensure to lay them in different suffixes in your user registry to that they don't ever overlap if you intend to have the same userid created in different secure domains. And as far as SecUser objectclass are concerned, they are laid out in sub-ou containers such as the following assuming you create secure domain tenantA, tenantB, tenantC, …

• cn=users,secAuthority=tenantA,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantB,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantC,cn=Subdomains,secAuthority=default

You can have only one-level of subdomain. When you start creating secure domains, I encourage that you create one for every of you end-user communities (or tenants) so that in the end, the "Default" secure domain is nothing else than an empty top-level admin domain. This way, there can be no confusion about any assumed higher authority/permissions that resources in one sub-domain have other the others.

A use-case for this can sometime be to run several "tenants" inside the same appliance/infrastructure.

In our case, we did not implement ISAM Secure Domain for the purpose of delegated administration but rather this was for completely segmenting administratively each "tenant" into their owner "container".

Heads-up: When implementing ISAM secure domain, if you have any provisioning solution connected to your ISAM deployment (such as ISIM for instance), you will need to adjust those provisioning workflows to ensure to provision users in the right ISAM secure domain; ISIM provisioning adapter such as the "ISIM TAM Combo Adapter" support provisioning users in different domains although you might need to configured several instance of that service in ISIM.

We've never used ISAM Secure Domain for the sole purpose of delegated user administrations, however.

The sole components that can bridge between the numerous ISAM secure domain created (Default and other) is the ISAM Policy Server; there will not be a unique instance per domain. The ISAM Policy Server will create a new master authorization database for every new secure domain: this is how it is ensuring that all resources and their permissions are isolated by domain. For instance, an ACL created in tenantB will not be made available in tenantC for instance nor in the Default domain.

Hope this helps.

Hi Jens,

Sorry. what I meant to recommend is to create separate LDAP suffixes for your containers of  inetorgperson (or similar) objects. For instance, your secuser objects and inetorgperson could be laid out as follow:

1. SecUser hierarchy (you don't decide that, ISAM will do it for you upon creation of each sec domain) – below these all fall under the same "secAuthority=default" LDAP suffix:

• cn=users,secAuthority=default
• cn=users,secAuthority=tenantA,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantB,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantC,cn=Subdomains,secAuthority=default
• 2. Whereas for your inetorgperson suffix hierarchy, it could look like this:

• ou=people,dc=abc,dc=tenantA (LDAP suffix dc=abc,dc=tenantA)
• ou=people,dc=abc,dc=tenantB (LDAP suffix dc=abc,dc=tenantB)
• ou=people,dc=abc,dc=tenantC (LDAP suffix dc=abc,dc=tenantC)

Note also that there is a configuration entry you can add (ivmgrd.conf) to further isolate between your different LDAP suffix containers (different domains):

• [domain=tenantA] allowed-registry-substrings = dc=abc,dc=tenantA
• [domain=tenantB] allowed-registry-substrings = dc=abc,dc=tenantB
• [domain=tenantC] allowed-registry-substrings = dc=abc,dc=tenantC

This will make sure that users don't end-up in the wrong LDAP container (suffix) by mistake by an admin.

Again, you don't have to create new LDAP suffixes for every of your new domain. This is just a recommendation. You could very well also create a single new LDAP suffix for all your inetorgperson objects, but then you still need ensure to segment them somehow (by OU containers …).

Cheers

In ISAM, it is called "secure domain". Everything you put in a new secure domain remains there and shielded from other domains. You can add users, groups, acl, pop, junction, … and server daemons (such as webseal, AuthZ) must be configured and inserted in corresponding secure domain. In other word, a particular webseal instance once configured against a secure domain can only serve users (and other resources) of that domain. You can run several webseal instances that are member of different domains on the same appliance. Also, once a user is created inside a particular secure domain, they cannot participate in other secure domains.

When implementing ISAM secure domain, you will want usually (as best practice advise) to ensure to lay them in different suffixes in your user registry to that they don't ever overlap if you intend to have the same userid created in different secure domains. And as far as SecUser objectclass are concerned, they are laid out in sub-ou containers such as the following assuming you create secure domain tenantA, tenantB, tenantC, …

• cn=users,secAuthority=tenantA,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantB,cn=Subdomains,secAuthority=default
• cn=users,secAuthority=tenantC,cn=Subdomains,secAuthority=default

You can have only one-level of subdomain. When you start creating secure domains, I encourage that you create one for every of you end-user communities (or tenants) so that in the end, the "Default" secure domain is nothing else than an empty top-level admin domain. This way, there can be no confusion about any assumed higher authority/permissions that resources in one sub-domain have other the others.

A use-case for this can sometime be to run several "tenants" inside the same appliance/infrastructure.

In our case, we did not implement ISAM Secure Domain for the purpose of delegated administration but rather this was for completely segmenting administratively each "tenant" into their owner "container".

Heads-up: When implementing ISAM secure domain, if you have any provisioning solution connected to your ISAM deployment (such as ISIM for instance), you will need to adjust those provisioning workflows to ensure to provision users in the right ISAM secure domain; ISIM provisioning adapter such as the "ISIM TAM Combo Adapter" support provisioning users in different domains although you might need to configured several instance of that service in ISIM.

We've never used ISAM Secure Domain for the sole purpose of delegated user administrations, however.

The sole components that can bridge between the numerous ISAM secure domain created (Default and other) is the ISAM Policy Server; there will not be a unique instance per domain. The ISAM Policy Server will create a new master authorization database for every new secure domain: this is how it is ensuring that all resources and their permissions are isolated by domain. For instance, an ACL created in tenantB will not be made available in tenantC for instance nor in the Default domain.

Hope this helps.

Hi Jens,

As Jon noted, Secure Domains, i.e. Subdomains, is not a good fit when using Basic Users.  The option allowed-registry-substrings does not affect the Basic User searches.  There are some work-arounds that are possible using LDAP ACLs but it tends to be a problematic solution.  I do not recommending using Subdomains with Basic Users.

The creating using the CLI is just:

pdadmin sec_master> domain create tenantA tenantA_sec_master passwordA
pdadmin sec_master> domain create tenantB tenantB_sec_master passwordB
pdadmin sec_master> domain create tenantC tenantC_sec_master passwordC

pdadmin sec_master> domain list
tenantB
tenantA
tenantC

This results with the following in LDAP:

secAuthority=Default
secAuthority=tenantA,cn=Subdomains,secAuthority=Default
secAuthority=tenantB,cn=Subdomains,secAuthority=Default
secAuthority=tenantC,cn=Subdomains,secAuthority=Default

We do have customers that use them successfully but they are using full imported ISAM secUsers not Basic Users.

It is possible to setup Delegated Administration using just the secAuthority=Default management domain.  Remember that sec_master, and the iv-admin group,  is not the same thing as root on UNIX.  Access can be controlled to the /WebSEAL tree as well as the /Management tree using ACLs and group memberships.
To give you a basic example, it is possible to create an object named /WebSEAL/Sales then apply ACLs such that only members of a group named sales-admin have access to create policy.  This locks out sec_master and say admins for /WebSEAL/Development.  It is also possible to create helpdesk type roles as well such that you end up with groups similar to:

sales
sales-admin
sales-pwdchg
sales-delete
sales-add

This can be fine-grained such that a member of sales-add has the ability to new users, but only when immediately adding that user to the sales group.  A member of sales-delete can only delete users.  A member of sales-pwdchg can change a user's password but not add or delete users.

This is all accomplished by placing ACLs on the /Management tree.  I suggest reading the /Management Permissions section in the Knowledge Center as a starting point.

We have customers that have implemented this successfully.