Versions Compared

Version Old Version 43 New Version 44
Changes made by

Andrew Petro

Andrew Petro

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We need to be able to support determining at runtime per request what kind of Credentials we have received and will be passing into the CentralAuthenticationService.

Discussion

Haven't I seen this before?

Yes, this is this page all over again.

Panel
titleLoginController inheritence

For reference, the following is the class hierarchy for LoginController. Highlighted methods are those involved in the discussion below.

Tip
iconfalse
titleLoginController

extends

Note
iconfalse
titleSimpleFormController

extends

Note
iconfalse
titleAbstractFormController
  • protected abstract ModelAndView processFormSubmission(
    HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception;
  • protected final Object getCommand(HttpServletRequest request) throws Exception;
  • protected Object formBackingObject(HttpServletRequest request) throws Exception {};

extends

Note
iconfalse
titleBaseCommandController
  • protected Object getCommand(HttpServletRequest request) {}
  • protected final Object createCommand() throws InstantiationException, IllegalAccessException;
  • protected final ServletRequestDataBinder bindAndValidate(HttpServletRequest request, Object command) throws Exception {}

extends

Note
iconfalse
titleAbstractController
  • public final ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {}
  • protected abstract ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception;

extends

Note
iconfalse
titleWebContentGenerator

extends

Note
iconfalse
titleWebApplicationObjectSupport

extends

Note
iconfalse
titleApplicationObjectSupport

...

This doesn't appear to get us where we need to be, though. We need to be able to support switching among several different types of Credentials.

Note
titleWhy several different types of credentials in one LoginController instance?

A draft of this document prompted the question

"Why does an instance of a LoginController need to support more than one type of Credentials?"

Any given CAS deployment might want to support more than one type of credentials. Say, username/password and also desktop Kerberos. So we'd have two radically different kinds of Credentials.

One way to handle this would be to have multiple instances of the LoginController, one for each type of credentials we might handle. But how did we know which LoginController to go to? We probably shouldn't switch on the URL, since after all any given CAS client is going to redirect to the single institutional CAS login URL regardless of end user preference about what kind of credential she wants to present.

Another way (I propose) is to give our LoginController a plugin, a RequestToCredentials. This object is responsible for examining the HttpServletRequest and returning the Credentials it represents. It is these credentials that get passed from LoginController into the CentralAuthenticationService for processing.

One plausible implementation of this interface will be the implementation that delegates to a List of other implementations, returning true to supports() if any of its children support the presented HttpServletRequest and returning the Credentials returned by the first of its children to support the request.

We might have mapped AuthenticationHandlers for Password credentials and for Kerberos credentials, say. The current LoginController implementation requires us to name the class an instance of which will be our Credentials once for the entire instance of LoginController. Per each request we can only configure the Credentials instance that has already been created for us.

...