The main configuration file for the MCB controls the logic used to provide the assurance levels requested by each Service Provider. This file is loaded by the MCB configuration bean from the Spring configuration file. Each section of the file is detailed below and a complete example is attached for reference.
This is the Velocity configuration file used by the MCB. It controls where the templates are loaded from and how often the Velocity engine checks for modifications.
On the initial authentication of a user, some choice must be made about how to authenticate the user. This option is a list of the authentication context values you as the administrator wish to present to the user. If there is only a single choice, then the user will immediately be sent to that method. If there are more than one, then the user will be presented with a list to choose from. This process can be modified by setting the requestedOnly value to true. If it is set to true, then the list of choices will be filtered by the requested values sent by the SP. However, if the SP sends no matching context values, the MCB will default to the list as given. Once initial authentication has occurred successfully, then the MCB will validate the other rules about which context values which users are allowed.
In order to validate that a given user is allowed to use a certain context level, the MCB must be able to obtain the list from some source. This is done by tying in with the standard Shibboleth attribute-resolver.xml file. The value given here is the ID value of an attribute resolver rule that contains those choices. Once a user is authenticated, the attribute resolver will be called to resolve those values and use them in the decision making process.
This option allows the administrator to allow a user to successfully authenticate to a SP if the user does not have a context assigned to their identity in the IDMS and the SP does not request any context value. By setting this value to false, the behavior of regular Shibboleth authentication will be used. If the SP requests a context value, this option is ignored. If the user has a context assigned, this option is ignored.
The maximum number of times a user may fail login before being redirected back to the Service Provider with a SAML error response. A value of -1 disables the option.
This section is the heart of the MCB. It defines which authentication contexts the MCB knows about, how it authenticates a user for that context, and how these context values relate to one another in terms of strength and precedence. Each context node gives the authentication context name it represents. It also specifies which authentication method is to be used to authenticate for that context. The allowedContexts list is a list of higher strength context values which can be substituted for this context. So in the above example, the password context can also be satisfied by the bronze context. The bronze context itself can be satisfied by the silver or silver-token contexts. So if a user authenticates via bronze and later accesses a SP that only requires password, they would be allowed access without re-authentication. If however, they then access a SP that requires silver, they would be prompted to re-authenticate via the silver context and its configured method.
Any number of context values may be specified.
You may NOT define a circular reference within the context section. The MCB will check for circular dependencies on start up and throw a fatal exception if one is found.
Authentication methods are implemented by the submodules defined in the Spring configuration file. Each method has a name which corresponds to the method attribute of the context definitions (tying them together). Each method also has a bean name which ties back to the Spring definition. Finally, each method has a value that is used as the friendly display name during the authentication selection process by the user. Each context defined must have a method that can be used to satisfy it. Note that multiple context values may use the same method. In that case, a user completing authentication by that method is satisfying all context values the user is allowed to use that have that method configured. As an example, if you define the password and bronze contexts to both use the password method, then the user will have completed both authentication contexts (password and bronze), assuming the user is allowed to use both password and bronze. This is true even if the selection choice was for password (implying bronze is a higher level of authentication).