Micro Services

Backend Providers, hereby “providers”, are responsible for retrieving and validating a user’s identity. A provider can perform any series of HTTP requests or other logic. The end goal of a provider’s execution is to obtain an identifier (or a claim) for the user.

A provider may handle user authentication with Rutgers Central Authentication Service (CAS), for example. Under the hood, a Backend Provider Handler executes the login flow with configuration details pertaining to Rutgers’ specific CAS implementation. This configuration comes from a Backend Provider instance.

Backend Provider Hander: General implementation of code to authenticate with a provider (CAS)
Backend Provider: Specific implementation of configuration to authenticate with a provider (Rutgers CAS)

A Backend Provider Handler on its own is not useful. It knows how to authenticate with CAS, but not what CAS instance to connect to specifically. The same logic applies for Backend Providers on their own. A Rutgers CAS Backend Provider knows the configuration details for Rutgers CAS, but not how to actually connect or use them.

Oftentimes, when referencing “providers”, we are really referring to a Backend Provider with a specific Backend Provider Handler attached.

What happens when a Backend Provider authenticates?

Providers operate with a goal of acquiring an identifier for a user. When this identifier is acquired, a new Backend Session is created to regulate its usage.

Users do not need to authenticate with the same provider many times in a short period of time. This is a means of improving user experience.

When a Backend Session is created, the Backend Session remembers the user’s identifier and associates it to their machine via a cookie. If they attempt to login again via the same Backend Provider, they will automatically utilize the existing Backend Session without re-authenticating. Thus, it is possible for a user to log into Rutgers CAS once and connect to a number of end applications.

How are Backend Sessions used by each end application?

While a Backend Session is reused multiple times to support the above scenario, each end application receives its own Ticket for its own usage. No two apps utilize the same Ticket, even if they are utilizing the same Backend Session. This prevents one end application from utilizing its login to control another end application.

A Ticket is issued as an extension of a Backend Session. When an underlying Backend Session expires, its associated Tickets also expire. This happens naturally after a configured lifetime, or manually via a logout procedure (TBD).

Throughout this process, the end application only receives a Ticket. It does not have any awareness of underlying providers or Backend Sessions. This ensures that end applications remain provider agnostic and secure.

Validation

Tickets are validated on each user request by the end application. The end application does this by taking the user’s Ticket and requesting that the service check its validity via a back channel request.

If the Ticket is still acceptable and the Backend Session is still active, the end application can use the user’s identity. Otherwise, an error will be returned and the end application can either opt to display an error or automatically try and reauthenticate by creating a new RequestToken and completing the login flow.