Specific Authentication Type required - multiple proxies

A proxy interacts with a second proxy unaware that the current authentication will be insufficient to access a backend service that the second proxy intends to use. In this case the first proxy (which communicates with and can redirect the browser to CAS) is not able to directly access the service string of the backend service and is therefore unable to tell CAS what type of authentication is required. However, CAS will have experienced either a failure to vend a proxy service ticket or a ST validation failure due to insufficient authentication against that service, and at the moment of failure CAS had access to the proxy chain. So rather than require the applications to pass details of the failure back though their own black box protocol that may not have bandwidth for such information, let CAS remember the most recent authentication type or level failure chained to the login TGT and indexed by the first Service on the proxy chain.

In this use case, a user attempts to access an application such as a portal that requires CAS authentication but does not require a specific authentication type.  This application then connects using proxy CAS to other applications that do require a specific type of authentication.

This use case requires extensions to the CAS protocol.

Actors

• User / Browser
• CAS Authentication (aka CAS authN)
• CAS validation
• CAS proxy authentication
• Application A - the application the user / browser connects to.  Application A does not require specific type of authentication.
• Application B - the application that application A proxies to.  Application B also does not require a specific type of authentication
• Application C - a backend service called by Application B using proxy tickets that does requre a specific type of authentication

Pre-Conditions

• PRE1: CAS is configured to support multiple authentication types (multiple authentication handlers).
• PRE2: Application B is configured in the CAS service registry including the type of authentication
• PRE3: A default type of Authentication such as "NetidPassword" is assumed when no other type is specified, and all existing services are assumed to require the default Authentication unless configured otherwise.

Flow

The bold lines are where the CAS protocol needs to be extended to support this use case.

1. User authenticates to Application A
   1. User / Browser request goes to the Application A with no service ticket.
   2. Application redirects browser to CAS authN
   3. CAS authN uses service string in URL to look up service in service manager registry and discovers application A uses default authentication type.
   4. CAS uses default authN flow
   5. On success, CAS sends response with service ticket and service url to browser
   6. browser sends request to application with ticket.
   7. Application sends ticket to CAS validation
   8. CAS validation looks up service in service manager registry, discovers type of authentication required and verifies that authN is valid
   9. CAS validation returns CAS 2 protocol response and delivers proxy granting ticket (PGT) to Application A
   10. User is able to use the application
2. Application A needs to connect to application B with proxy service ticket.  
   1. Application A uses PGT delivered during user authentication (above), to request a proxy service ticket for Application B
   2. Application A sends the proxy ticket to B
   3. Application B obtains a PGT
   4. Now there are many variations on what happens next, but the details don't matter. It may be that Application C requires a specific level of authentication or it may call a service that calls a service that requires a specific level of authentication. It also doesn't matter if the problem is detected when CAS rejects a request for a proxy service ticket because of the service name or if the service ticket fails to validate because of additional parameters introduced into the service ticket validate protocol to allow specification of a specific type of authentication dynamically.
   5. At the point of failure (failure to vend a proxy service ticket or failure to validate a ticket) CAS chains a new control block off the login TGT. This new block remembers the type of authentication that was required but was not present in the last failure and the service ID of the first element on the Proxy Chain (in this case, the service of Application A).
   6. Application C returns to B, or B returns to A with some error. Since the nature of the call and return are not part of the CAS protocol and may have no room for expansion of parameters or return codes, we cannot assume that any information can be returned through this protocol.
   7. If Application A is suspicious that the failure was due to inadequate authentication, a new information Web call should be available from CAS to present his PGT and obtain confirmation that an authentication type failure occurred somewhere down his proxy chain and the service string (or type parameter) associated with the failure.
   8. Application A can now redirect the Browser to CAS with parameters to acquire the missing authentication type in the same way and using the same protocol as the case where he determined that B itself required a particular type of authentication.

By indexing the failure using the service ID of the first element of the proxy chain, we handle the case where the user is logged into two proxy hosts at the same time and the authentication problem applies to only one host. However, if multiple authentication failures occur in the same request (say using multiple portlets in the same portal) and each requires a different specific factor, then because we only remember the last failure in the chain there will be a sequence of failures and returns to CAS until all authentication requirements are resolved. This is not likely to be a problem in the real world.

This scenario assumes that Application A receives some indication that some failure occurred that might be associated with an authentication problem and knows enough to query for the problem using the new parameter. If the Proxy Service Ticket protocol is extended to include failure information when there is insufficient authentication for the requested service, there might also be a secondary warning return when the proxy service ticket was provided but there was also a previously detected and as yet unreported authentication failure in the proxy chain. That way Application A might at least become aware of the problem deep down the chain the next time it uses its PGT.