Expand Collapse
Just a second...

User-written authentication handlers

You can implement authentication handlers that authenticate clients that connect to the Diffusion™ server or perform an action that requires authentication.

The authentication handlers can be implemented either remotely, in a client, or locally, on the server. The authentication handlers can be individual authentication handlers, that perform a single authentication check, or composite authentication handlers, that delegate to one or more individual authentication handlers.

Local authentication handlers

A local authentication handler is an implementation of the AuthenticationHandler interface. Local authentication handlers can be implemented only in Java™. The class file that contains a local authentication handler must be located on the classpath of the Diffusion server.

For more information, see Authentication API.

Control authentication handlers

A control authentication handler can be implemented in any language where the Diffusion Unified API includes the AuthenticationControl feature. A control authentication handler can be registered by any client that has the authenticate and register_handler permissions.

For more information, see Authenticating clients.

Composite authentication handlers

A composite authentication handler delegates the authentication decision to an ordered list of one or more individual authentication handlers and returns a combined decision.

Figure 1. A composite authentication handler A composite authentication handler delegating to three individual handlers. If an individual handler allows or denies the client action, the composite handler responds with an allow or deny. If an individual authentication handler abstains, the composite handler calls the next individual handler. If all individual handlers abstain, the composite handler responds with an abstain decision.
  • If an individual handler allows the client action, the composite handler responds with an ALLOW decision.
  • If an individual handler denies the client action, the composite handler responds with a DENY decision.
  • If an individual authentication handler abstains, the composite handler calls the next individual handler.
  • If all individual handlers abstain, the composite handler responds with an ABSTAIN decision.

A composite authentication handler can be either local or control. A local composite authentication handler can delegate the authentication decision to one or more authentication handlers. A composite control authentication handler can delegate the authentication decision to one or more control authentication handlers.

The use of composite authentication handlers is optional. There are two reasons to consider using them:
  • Composite authentication handlers enable you to combine authentication handlers together, which reduces the possibility of misconfiguration.
  • Composite control authentication handlers improve efficiency by reducing the number of messages sent between the Diffusion server and clients.
The following table matrix shows the four types of authentication handler.
Table 1. Types of authentication handler
  Individual Composite
Local Implement the AuthenticationHandler interface. For more information, see Developing a local authentication handler. Extend the CompositeAuthenticationHandler class. For more information, see Developing a composite authentication handler
Control Implement the ControlAuthenticationHandler interface. For more information, see Developing a control authentication handler. Extend the CompositeControlAuthenticationHandler class. For more information, see Developing a composite control authentication handler

This page last modified: 2017/05/24