Configuring domains

A minimal Authentication Gateway configuration requires at least one domain entry. Without domain configuration information, the OESTS implementation will not work. Other domains may be provided, and optionally, ABL policy and event callback handlers may also be defined.

Domain configuration files

Domain configurations are stored in instance/webapps/ROOT/WEB-INF/config/domains.json, where instance is the name of the instance where your OESTS web application is deployed. This is a simple JSON-formatted text file that can be edited to define domain entries.

The domains.json file

The default blank domain is configured to use a property file as the authentication mechanism. This file is stored in instance/webapps/ROOT/WEB-INF/config/users.properties. This default domain configuration is simplified intentionally to make initial development easier, but using the blank domain at later stages is not recommended, especially in a multi-domain environment.

A domain configuration defines the authentication provider to be used for login (see Spring Security Configuration for more information), the ABL policy for the domain, the event handler implementation, as well as additional context information that can be used by policy and event callback handlers.

The following is a sample domains.json file that defines a single domain given a blank domain name. The domain is enabled and is marked as supporting both Single Sign On (SSO), and login (authenticate) operations. The last required entry is the name of the authentication provider implementation. In this case, it is named properties. The properties authentication provider is configured to use a users.properties file with a couple of simple default user/password combinations for testing purposes.

{
"version": "1.0.0",
"domains": [
{
"name" : "",
"enabled" : true,
"description" : "Default domain",
"actions" : {
"authenticate" : {
"enabled" : true,
"options" : ""
},
"exchange" : {
"enabled" : false,
"options" : ""
},
"sso" : {
"enabled" : true,
"options" : ""
},
"refresh" : {
"enabled" : false,
"options" : ""
}
},
"options" : "",
"authProvider" : "properties",
"policyProvider" : "",
"events" : {
"provider" : "",
"groups" : {
"client" : false,
"tokenAuthenticate" : false,
"tokenExchange" : false,
"tokenRevoke" : false,
"tokenValidate" : false,
"tokenRefresh" : false,
"policy" : false,
"sessionLogin" : false,
"sessionLogout" : false,
"sessionValidate" : false,
"sessionRefresh" : false
}
}
},
{
"name" : "oests.server",
"enabled" : false,
"description" : "STS server key domain",
"actions" : {
"authenticate" : {
"enabled" : false,
"options" : ""
},
"exchange" : {
"enabled" : false,
"options" : ""
},
"sso" : {
"enabled" : true,
"options" : ""
},
"refresh" : {
"enabled" : false,
"options" : ""
}
},
"options" : "",
"authProvider" : "anonymous",
"policyProvider" : "",
"events" : {
"provider" : "",
"groups" : {}
}
}],
"policyProviders" : {

},
"eventProviders" : {

}
}

Configuration file monitoring

The domains.json, domains.keystore, and users.properties configuration files are actively monitored for changes by the OESTS application. If a change is made to one of these files, the changes will be applied without restarting the OESTS application. The files are read at startup of the OESTS web application and again after the files have changed.

Configuration file location

You can change the location and name of the OESTS configuration files by editing sts.properties file. This file is stored in instance/webapps/ROOT/WEB-INF/config/users.properties. By default, configuration files are referenced as relative file paths from the web application. Edits to sts.properties require a restart of the OESTS web application or the Authentication Gateway itself.