More thoughts on Authentication module: Yale discussion 1/19

AuthenticationHandler.supports()

Scott had commented:

This version of the AuthenticationHandler is missing a very important method.... supports(Credentials credentials). This method determines if a specific handler can even attempt to authenticate these credentials. Its also a reason for the existance of the AuthenticationManager

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 or didn't honor the result of supports().
2. Using two calls allows for intervening changes to lead to inconsistency. It is far fetched but not 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

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."

Considering the concept of authentication type led us to CAS 3 support for SAML concepts. Likely concepts to support include time of authentication (as opposed to ticket), authentication class, authenticator attributes. See SAML spec. To support SAML, the AuthenticationResult object must be capable of representing 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 a more general function allows the target 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. The AuthenticationResponse would indicate that the authentication context was derived from a client certificate. SAML schemas specify appropriate data model.