ConditionalDispatcherState

Introduction and overview

This ConditionalDispatcherState allows configuring an arbitrary number of conditions based on variable expressions and LDAP filters to address different follow-up steps in the authentication state engine.

Description

The following table and chapters describe the characteristics of the AuthState.

Topic	Description
Class	ch.nevis.auth.auth.states.standard.ConditionalDispatcherState
Logging	StdStates
Auditing	none
Marker	none
Methods	process

Properties

• connection1, ..., connection9, baseDN (string)

  Properties required for LDAP conditions. See a description of analogous properties in UseridPasswordAuthenticateState.

• searchSizeLimit (int, 256)

  See the corresponding property description in UseridPasswordAuthenticateState.

• selectBestTransition (boolean, false)

  If configured to true, this option causes the AuthState to select the transition with the most conditions for which all conditions are satisfied. If set to false, prioritization is not used and multiple conditions have the same result it will result in an AuthStateException.

• prioritization (string, -)

  A list of transitions, separated by whitespace, sorted by priority. If multiple transitions are selected by the ConditionalDispatcherState and have equal weight, the prioritization provides an order so that the state can decide which transition to take.

  Prioritization is evaluated only if selectBestTransition is set to "true".

  Deprecated

  The use of the prioritization option is deprecated and discouraged. It is not supported in the Admin4 pattern. We recommend defining clear conditions and splitting complex dispatching flows into multiple chained conditional dispatcher auth states to have deterministic runtime behaviour.

• condition:<transition-name> (string)

  The value of the property may contain any expression, but it is usually used to query directories for specific data to be considered for further authentication processing. For the condition to hold, the value must evaluate to a non-empty string. If the value is prefixed with the identifier ldap:, it is treated as an LDAP query. If multiple conditions are present, they are all evaluated and the most selective transition is set.

  The example section below shows the configuration possibilities: An already authenticated user is treated differently based on authentication strength and employee status in the directory.

  The condition value may also contain one of the following comparison operators:

  • == comparison with exact case matching
  • ?= case-tolerant comparison
  • != inverse comparison ("not-equals")
  • !?= inverse case-tolerant comparison

  Be aware that this syntax is limited. The condition value must not be used to accommodate arbitrarily complex logic. Specifically, this concerns the comparison operators: During processing, the condition value string is split mechanically on the first operator encountered. Then the left-hand side and the right-hand side substrings are each evaluated separately, before being compared according to the comparison operator.

  For example, in a simple case like #\{inargs['activate']\}=='true'", the substrings "#\{inargs['activate']\} and 'true' are each evaluated and then compared (taking case into account).

  This procedure breaks down with more complex condition values such as #{inargs['activate']=='false'}==#{session:myvar}, where splitting mechanically on the first == operator obviously does not yield substrings that can be evaluated as expressions. It is therefore recommended to use an EL expression (see Java EL expressions) with a comparison utility method like StringUtils.equals instead to construct more complex condition values.

Input

none

Transitions

The transition is set on evaluating the configured conditions in the current request context. Multiple conditions may be used in a single transition, forming a comma-separated list. A transition will only be selected if all its conditions hold.

• nomatch

  In case none of the conditions matched, a nomatch transition will be set.

• default

  Used in case conditions matched, but the result condition contained other dispatching restrictions, such as those described in AuthState results and transitions.

Output

none

Errors

none

Notes

none

Example

<AuthState name="LdapCheckEmployeeDispatcher"
   class="ch.nevis.esauth.auth.states.standard.ConditionalDispatcherState" final="false">
  <ResultCond name="isEmployee,isWeak" next="AuthDoneIntranet" />
  <ResultCond name="isEmployee" next="AuthDoneB2BPortal" />
  <ResultCond name="isWeak,isStaff" next="StaffStepup" />
  <ResultCond name="default"    next="AuthDoneB2CPortal"/>
  <Response value="AUTH_ERROR">
    <Gui name="AuthErrorDialog"/>
  </Response>
  <propertyRef name="LdapLogin"/>
  <property name="condition:isWeak"
            value="${request:authLevel:^auth.weak$}" />
  <property name="condition:isEmployee"
            value="ldap:(&amp;(cn=${inargs.isiwebuserid})(&amp;(objectClass=User)(!(employeeType=I))))"/>
  <property name="condition:isStaff" value="${sess:user.unit}==staff"/>
</AuthState>