In OpenEdge 11.7.5+ and 12.1+, support has been added for multiple fully qualified domain names (FQDs) in OpenEdge Authentication Gateway. Support for domain-qualified user IDs solves an issue for users who perform multi-tenant account lookup and information retrieval: their authentication services are now able to customize access to tenant-aware user account storage, and add tenant specific information to Client-Principal security token fields.

To configure multi-domain user ID support in OpenEdge Authentication Gateway, follow these instructions:
  1. Open the domains.json file for your target web application. For example, oeauthserver-name/webapps/ROOT/WEB-INF/config/domains.json, where oeauthserver-name is the name of the instance where the OESTS web application is deployed.
  2. Edit the domains.json file to include the FQDN used during the authentication process. For example, if your authentication method is LDAP, and the domain for your application is employee01@progress, add or edit the domain entry to the list:
    {       
      "name" : "PROGRESS",       
      "enabled" : true,       
      "description" : "LDAP Multi domain authentication",       
      "actions" : {            
		"authenticate" : {                
			"enabled" : true,                
			"options" : "-useFQUserIds"            
		},            
		"exchange" : {                
			"enabled" : true,                
			"options" : ""            
		},            
		"sso" : {                
			"enabled" : true,                
			"options" : ""            
		},            
		"refresh" : {                
			"enabled" : false,                
			"options" : ""            
		}       
      },       
      "options" : "",       
      "authProvider" : "ldap",       
      "policyProvider" : "",       
      "events" : {            
		"provider" : "",            
		"groups" : {}       
      }    
}
    The value that allows for multi-domain support is the -useFQUserIds switch. Once added, the OpenEdge Authentication Gateway will pass a fully qualified OpenEdge user ID to whichever authentication provider (“authProvider”) is configured.
    Note: The authentication providers where the -useFQUserIds option can be most useful are OERealm and LDAP because OERealm supports multi-tenant-enabled user accounts, and LDAP can use the fully qualified user ID as an email account name.
The following rules are used by the OpenEdge Security Token Service (STS) web application for constructing and passing a fully qualified user ID to an authentication provider:
  1. If the client input contains a blank OpenEdge Domain subfield, the user ID is passed to the authentication provider unaltered. A static OpenEdge Domain name can be configured to be appended to the user ID after a successful authentication.
  2. If the client input contains a non-blank OpenEdge domain subfield, and the -useFQUserIds option is not specified, then only the user ID subfield is passed to the authentication provider. Upon successful authentication, the client-specified fully qualified user ID is placed into the sealed Client-Principal.
  3. If the client input contains a non-blank OE Domain subfield, and the -useFQUserIds option is specified, then the client-specified fully qualified user ID is passed to the authentication provider unaltered. Upon successful authentication, the fully qualified user ID is placed into the sealed Client-Principal.

The following table shows various client user ID inputs and what values are passed to authentication providers:

Client Specified User ID Without -useFQUserIds With -useFQUserIDs Inserted Into Client-Princpal
user1 user1 user1 user11
user1@domain1 user1 user1@domain12 user1@domain1
user1@email@domain1 user1@email2 user1@emain@domain1 user1@email@domain12
1 The optional @domain may be blank, a configured static value used by all OpenEdge Domains, or a value derived from one of the user account’s granted group/role memberships.
2 The user1@domain1or user1@email may be passed to an LDAP authentication provider when the user search filter includes matching the LDAP user account’s email attribute.