More thoughts on Authentication module: Yale discussion 1/19

AuthenticationHandler.supports()

The concept of Authentication Type was raised by RU scenario where credentials include type.

"at Rutgers our CAS now accepts Username, Password and AuthenticationType (Safeword, Normal, etc.) as credentials."

To complete the authentication the authentication manager needs to discover what type each authentication handler supports.

We see the supports method as functionally equivalent to an AuthenticationResult return object which could include additional information from the handler such as "request not supported". It seems preferable to eliminate supports and accomplish the function in one call for two reasons:

1. Even if the supports method exists the AuthenticationHandler will need to handle the "request not supported" condition in the case that the caller didn't bother to call supports().
2. Using two calls allows for intervening changes to lead to inconsistency. It is far fetched but impossible to imagine a dynamic provider which can support a type when supports is called but can't handle it by the time the authenticate method is called.

Authentication Type

We consider the future of CAS to include support for SAML. To ensure this, the AuthenticationResult object needs to represent all information which might be needed for SAML assertions about authentication such as time and context.

Example

In CAS 2 a service can request "renew=true" as part of the redirect to CAS and can ensure that in the process of acquiring a valid ticket the user was required to supply primary credentials. In CAS 3 the function can be greatly expanded to allow the service to request a type of authentication. For example imagine an aplication which only trusts user with client certificates not just those who know their password. In CAS3 the service would have the means through redirect and validate to ensure that its service ticket is derived from an authentication which included a valid client certificate.