Skip to main content
Version: 4.32.x.x LTS

Configuration structure

The following configuration fragment defines a domain SSO1 that requires the reverse proxy to reauthenticate on an established session (after an inactivity time-out of 300 seconds) and to terminate the session after a period of user inactivity (time-out of 1800 seconds). The domain defines initial authentication, session unlocking methods and authentication stepup methods:

<AuthEngine name="TheAuthEngine"
classPath="/opt/nevisauth/plugin:/var/opt/nevisauth/default/plugin">
<Domain name="SSO1" default="true" reauthInterval="300" inactiveInterval="1800">
<Entry method="authenticate" state="LoginUidPw"/>
<Entry method="unlock" state="LoginUidPw/>
<Entry method="stepup" state="LoginOneTimePw"/>
</Domain>
<AuthState name="LoginUidPw" ...>
<ResultCond name="ok" next="LoginOneTimePw"/>
....
</AuthState>
<AuthState name="LoginChangePw" ...>
....
</AuthState>
<AuthState name="LoginOneTimePw" ...>
<ResultCond name="ok" next="AuthDone"/>
....
</AuthState>
<AuthState name="AuthDone" ...>
....
</AuthState>
<AccessController>
....
</AccessController>
</AuthEngine>

Classpath configuration

It is possible to configure nevisAuth with a separate classloader for the authentication plug-ins (AuthStates). This allows a separation of the classpath of the container and of nevisAuth itself.

By default, the system loads the AuthState classpath by using a PARENT_FIRST classloader strategy, that is, it loads classes from the container's runtime environment first. The nevisAuth package sets the default AuthEngine classPath (if not configured) as follows:

/opt/nevisauth/plugin:/var/opt/nevisauth/$INSTANCE/plugin

This means that

  • The system loads nevisAuth's standard AuthStates and their implementation-specific dependencies from the software directory (/opt/nevisauth/plugin or according to the classPath of the AuthEngine) by default.
  • It is possible to copy setup-specific AuthStates to /var/opt/nevisauth/$INSTANCE/plugin, to be automatically located by nevisAuth. Alternatively, you can place the plug-ins in a separate location and extend the classPath attribute of the AuthEngine accordingly.

AuthStates can also define their own classpaths via the classPath and classLoadStrategy attributes in the same way.