Multi-Factor Non-Interactive User Login Use Case

In this instance, non-interactive user login refers to the typical proxy authentication use case

Actors

User has already authenticated to client satisfying its CAS authentication policy (see Interactive Use Case)
User's session with the System is still active and valid
Client requires access to Non-Interactive Service ("proxied service") on behalf of the User
Client has ability to access services on behalf of the user.
Non-Interactive Service has a policy restriction

Client attempts to access Service on behalf of the user
1. If the Service's policy is satisfied, then the access is granted to the service. Flow Ends.
2. If the Service's policy is not satisfied, the flow continues.
Service notifies client that access was denied. Access can be denied for a variety of reasons:
1. Failed to validate token provided for traditional reasons (see traditional Proxy Authentication Use Case)
2. Failed to validate token provided due to authentication policy failure
3. Failed to validate proxy chain (see traditional Proxy Authentication Use Case)
Services that can notify the Client of the reason for the failure, should do so. The expectation is that MOST cannot do that.
Client asks System to identify reason for failure (non-policy reasons are out of scope for this document)
User provides System credentials that satisfy service and client policies (NOTE: in the instance of multiple service proxy chains, all policies must be satisfied)
Client invalidates its existing local session and establishes new session with authentications that satisfy it and service policies
Flow Restarts