Enhanced multi-domain support

The first generation of multiple OpenEdge domain support in PAS for OpenEdge was limited to the use case where the user-id entered by the client was a fully qualified OpenEdge ID, including both the user-id and the domain (or tenant) name. This type of user authentication works well when the back-end user account storage is implemented with multiple user domain capabilities.

An OpenEdge domain is a group of user accounts that all share the same access control rights. A tenancy is a security feature that attributes access control to data for all user accounts of all the domains associated with a single tenant. A tenant is required to have one domain in which all user account members are members of the tenant. Any tenant may be associated with multiple domains.

Another use case exists where the back-end system’s user account storage is not implemented with multiple user domain capabilities. An example of this is the Spring Security’s LDAP Authentication Provider, which can be found in PAS for OpenEdge web applications. The user account storage in the LDAP server is a flat space holding all user accounts for all domains, and each account has a unique ID. In this case, the domain name is not something the client supplies during authentication, but rather something that must be related to the user account itself.

This topic describes how PAS for OpenEdge now supplies multi-domain support for non-domain aware user account implementations.

The changes that update multi-domain support all occur in the Spring Security OEClientPrincipalFilter bean found in all of the oeablSecurity-*.xml configuration files. The OEClientPrincipalFilter bean has additional capabilities that allow it to derive a domain name from a user account’s granted roles.

This method of using Spring Security roles as OpenEdge domains follows the logical pathway where a user account becomes a member of an OpenEdge domain by virtue of being granted membership in the domain. This is the same reasoning used in LDAP directories when an administrator associates individual user accounts with an LDAP group for the purpose of controlling access.

The logic paths in the OEClientPrincipalFilter have been altered with respect to how an input OpenEdge ID is processed to yield the user-id and domain name. The user-id and domain are used in creating a client-principal object that is subsequently passed to the ABL application code.

The OEClientPrincipalFilter logic roughly follows the steps below when it is given control after Spring Security’s authentication provider has successfully authenticated the user:

The domainRoleFilter is a new property added to the Spring Security OEClientPrincipalFilter bean to support obtaining an OpenEdge domain name from a user-granted role. The domainRoleFilter property is a JavaRegEx pattern that is used to identify any role name produced by Spring Security and to extract the domain name from it. The basic concept is to use a role-naming convention to distinguish a role name that represents a domain from other role names.

The RegEx expression can be any valid pattern with a single extraction group (a RegEx pattern enclosed in parentheses). The full pattern is used to match a role name. Everything that matches the pattern enclosed in parentheses is extracted and becomes the domain name.

The following are examples of user role-naming conventions:

Spring Security authentication providers (the beans that authenticate user accounts) prefix ROLE_ to all role names provided for authenticated users. Since the role names presented to the OEClientPrincipalFilter bean are in the form ROLE_user-role-name, this is what would be matched by the domainRoleFilter property:

When the domainRoleFilter property is not defined or is a blank string, looking for a domain name in the user’s list of granted roles is disabled.

If you are working with a PAS for OpenEdge installed prior to the 11.6.2 release, you must install the 11.6.2o4glrt.jar and oesecurity-11.6.2.jar libraries.

To install:

After retesting to ensure that your application is operating normally, go to the next section on configuration.

Configuring for multi-domain support begins with the follow steps:

The next step is to design the role name pattern that will be used in the external user account systems to designate an OpenEdge domain. Ideally the name pattern will have a unique prefix that distinguishes it from all other names. The name pattern may also employ a postfix to help establish uniqueness.

When you have established a domain name pattern, construct the Java RegEx pattern that will distinguish the domain name from any other normal user account granted roles. For example, with OED:domain-name as the domain name:

The Spring LDAP Authentication Provider prefixes ROLE_ to any LDAP group name it uses as a user account role, and it converts the LDAP group name to upper case.

Testing, along with debugging and fine-tuning, may be required to get your implementation running optimally.

You can begin by testing your oeablSecurity-*.xml configuration using the local Spring user account text file. This gives you the ability to experiment offline with role names and configurations before moving on to a more complex user account source such as LDAP.

After making oeablSecurity-xx-local*.xml your Spring Security configuration in .../WEB-INF/web/xml, add trial users to .../WEB-INF/users.properties. For example:

You can use a favorite HTTP client to test logins.

The built-in ping functionality is easy to use on each PAS for OpenEdgeweb application. The syntax is:

If you do not get an HTTP 200 response from a ping, you may have a configuration problem and need to check log files to determine what it is.

To enable logging, add the following setting in .../WEB-INF/logging.xml:

Additional logging for selected parts of the Spring Security framework can be added if necessary:

Once you know your OEClientPrincipalFilter bean configuration is fundamentally working, you can move on to the more complex systems such as LDAP. LDAP is a very widely used directory service that is commonly employed at the enterprise level for secure common storage and administration of information with regard to servers, applications, user accounts, user groups (a.k.a., roles), and many other things.

Spring Security LDAP configuration details will almost always be unique to each individual enterprise; however, the following will give you information about configuring OpenEdge domains in the directory service so that the OEClientPrincipalFilter bean can find and use them.

Each LDAP directory service has a schema that defines its objects and object attributes. Different implementations of a directory service may vary in the objects and object attributes it supports. Examples of different directory services are:

An OpenEdge domain will be just another LDAP group object that contains a list of the user accounts (Distinguished Names) who are members of that group, and who are entitled to the access associated with the group. The difference is that the LDAP group’s name will be based on the name pattern you defined in the previous sections.

For example, directory service administrators use the LDAP groupofUniqueNames objects as user account roles, where each group member’s user account is in a uniqueMember attribute. The directory service’s hierarchical object space might look like the following:

In this simple example, the user account acmeuser1 is in the domain acme. This occurs because a group is defined with the name OED:acme, and the user account for acmeuser1 is a member of that group. Therefore, when Spring Security authenticates acmeuser1, it will see that acmeuser1 is a member in the ROLE_OED:acme. The role supplies the domain name acme for creating a client-principal’s domain-name field.