How delegation works

The delegation process redirects the start of an application or service to a delegation service to authenticate a user. To help you understand delegation, different scenarios for starting and/or refusing a service and the communication paths involved are illustrated.

Following steps are performed when a delegation occurs:

  1. An application or web service start is requested. The type of request is defined by the /ua/r or /ws/r path segments in the URI.
  2. The JGAS dispatcher passes the request to the REST service identified as the delegation service specified in the application's configuration. The delegation service is written in Genero and managed by the JGAS as a standard REST web service. The delegation service should reside on the same JGAS as the application.
  3. The REST service instructs the JGAS to:
    • Refuse the start of the application or service.
    • Allow the application to start. The delegate service is able to add some environment variables to give additional information to the allowed application.
    • Allow service to any request forwarded to it. All web service requests are in /ws/r so they all go to the delegate service.

The delegation REST service refuses the start of the application or service

In this scenario, the delegation REST service refuses the start of the application or service. The REST service communicates with the user agent in HTTP using the com.HTTPServiceRequest object. For example, it could return an XHTML form asking for a user name and password to grant access to the application or service.

Figure: REST service communicates with User Agent but does not start the application or service

Diagram shows the communication path from the user-agent to the dispatcher, from the dispatcher to the REST service GWSProxy. When the service refuses to start the application, the response is sent back to the user agent (by way of the dispatcher). The steps are detailed in the surrounding text.
In this figure:
  • (1) Start a new application or service of the form /ua/r or /ws/r.
  • (D) Delegate application or service start to the service described in the configuration file (xcf).
  • (2) Forward the request to REST service for delegation process.
  • (A) REST program responds directly to the User Agent (with a login page, for instance).
  • (3) (4) Response is sent back to the User Agent.

The delegation REST service allows the start of the application or service

In this scenario, the delegation REST service allows the start of the application or service as if launched directly from the user agent.

Figure: REST service approves application or service start

Diagram shows the communication path from the user-agent to the dispatcher, from the dispatcher to the REST service GWSProxy, back to the dispatcher, which then starts the application or service. All subsequent communication is between the application or service and the user agent (by way of the dispatcher). The steps are detailed in the surrounding text.
In this figure:
  • (1) Start a new application or service of the form /ua/r or /ws/r.
  • (D) Delegate application or service start to the service described in the configuration file (xcf).
  • (2) Forward request to REST service for delegation process
  • (B) Genero REST program allows the proxy (login and password are correct, for instance) to start.
  • (3) (4) Response is sent back to the User Agent.
  • (5) REST program response with HTTP code 307 and description string.
  • (C) Dispatcher detects REST command and starts the proxy
  • (6) Dispatcher forwards response from REST program to proxy
  • (7) (8) Any request is forwarded to the proxy without going to the REST service (except for GWS that starts a new delegation process).
To allow the application to start, the Genero REST service returns a specific HTTP code and description to the dispatcher using the com.HTTPServiceRequest object. When the dispatcher gets such an HTTP response from the REST service, it starts a new proxy and forwards the request to it, as if no delegation had taken place.