LCSR Identity Services - Internal Login Flow
When a user begins the login flow, many different processes occur to determine how to proceed through the flow.
Many backend authentication providers (hereby “backend” or “provider”) require the user to be directed to a special page to continue a flow. This page may be an internal login form (as seen in the LDAP provider) or an external site (as seen in the CAS provider). As such, the login flow is not a single request, but instead is composed of many individual requests, or steps, that ultimately result in a Ticket for the user’s end application.
Follow along with this document in the “App\Http\Controllers\Authentication\Controller@login” method.
The general login flow is as follows:
- The user is directed to the login endpoint with a RequestToken. The RequestToken is validated and its requesting end application is located.
- An appropriate backend is found for the login. If only one backend is registered to the end application, then it will be used. If multiple are available, the user is prompted to select one. Alternatively, the end application can manually “hint” a backend to use by passing its identifier in the “backend_id” request parameter.
- The login flow for the backend is commenced. The backend’s handler can return either a response object to pass onto the user or a BackendSession. When a session is returned, the backend flow is complete. If a response object is returned, it is expected that the user will be redirected back to the flow to continue until a BackendSession is eventually returned.
- Once a BackendSession has been returned, it is saved to the PHP session for future usage without invoking the previous step. If two applications utilize the same provider, they will not need to individually go through the entire backend provider flow. These BackendSessions are “remembered” for a configurable time period.
- A Ticket is created from the backend session.
- The end application’s configuration is queried to determine if the end user’s identifier (primary_claim) is permitted to impersonate others in the app. If the user is permitted, an interstitial screen is displayed to allow the user to either enter a new “override” identifier or continue as themselves.
- The service URL is constructed and the user is redirected back to the end application.