Security Federation

ESF lets you configure more than one External Security Manager (ESM). There are various reasons for using multiple ESMs. Some organizations use one ESM to authenticate users (for example, if your Enterprise Server users are also operating system users), and another to handle resource access. Others might use one ESM to perform the initial stage of user authentication, and a second one to make additional checks (for example, to restrict which OS users can sign in to ES/MSS facilities). And in other cases, user, group, and resource definitions might simply be split among ESMs for administrative reasons.

In some cases, you want ESF to treat multiple ESMs as if they were a single security manager, at least for some purposes. This is called federation. ESF 1.14 and later has an option to enable a degree of federation, for ESM Modules that support it.

You configure federation for all of ESF (in the security configuration for an ES server or MFDS), but it's actually implemented by individual ESM Modules. Each module takes different actions depending on the federation setting.

Currently only the MLDAP ESM Module has special processing for federation, and it only applies if you have multiple LDAP ESMs in the stack. Federation currently has no effect if you have no more than one instance of the MLDAP ESM Module in your configuration.

What federation does

When federation is enabled, ESM modules attempt to share information and responsibilities, so that multiple ESMs behave as if they all had the same information about users, groups, and resources. For example, suppose you have multiple LDAP repositories with security information: a user might be defined in one LDAP repository, and a resource access control rule in another. If you want the resource control rules from one LDAP repository to apply to users defined in another LDAP repository, you would enable federation.

Disabling federation, on the other hand, tells ESM modules to attempt to act independently of each other. With federation disabled, the access control rules defined in one ESM should only apply to users who are also defined in that ESM.

There is also a "compatibility" federation setting, which maintains the behavior of ESF 1.13 and earlier. If compatility federation mode is set, ESM modules may have some interaction, possibly leading to unexpected results in some cases. This is the default, to avoid introducing incompatible behavior in existing installations. However, if you have multiple ESMs configured ("stacked"), you should probably explicitly enable or disable federation.

If you are not sure what setting to use, try the following guidelines:

• If your configuration only has one ESM, you don't need to worry about configuring federation.

• If your configuration has multiple ESMs, but you aren't using the MLDAP ESM Module, or you only have one instance of the MLDAP ESM Module, you don't need to configure federation. You might want to, though, in case it becomes relevant in a later release.

• Do you define users in one ESM, and the groups they belong to in another? If so, you should enable federation (you expect your security information to be combined).

• Do you define users and/or groups in one ESM, and resource access rules that apply to them in another? If so, you should enable federation.

• Are the resource access rules defined in each ESM meant only to apply to users and groups known to that ESM? If so, you should disable federation (you expect your ESMs to act independently).

• If none of the above apply, you can probably disable federation.

Configuring federation

Federation is configured using the configuration text area of the relevant Security Configuration page in the MFDS administration user interface. This is the security configuration tab for an individual server, or the "Default ES Security" page in the global security settings, or the "MFDS Security" page - not the Security Manager Configuration page, where you specify the ESM Module name.

To configure federation, add the following section:

[Operation]
Federate=setting

where setting is yes, no, or compatible. The default is compatible, which preserves the behavior of ESF 1.13 or older.