Notice: This micro service is in a prerelease stage and may have breaking issues.
Identity Service
The LCSR Identity Services system provides a streamlined way to authenticate users for your application.
The system is designed to work with a number of backend authentication providers (CAS, Google, Microsoft) to allow for any use case.
The system is simple to implement. The below diagram represents the authentication process. This is the process your application will undergo to authenticate a user.
How the micro service can improve your application
The LCSR Identity Service allows your application to interface with a variety of different authentication providers through one unified system.
- One interface, many providers. Write your authentication logic once, and allow the micro service to handle differences from provider-to-provider. Easily configure your application to allow login from Central Authentication Service (CAS), Google oAuth 2.0, and more.
- Less time spent worrying about details. Let the micro service deal with changes from providers and new API versions. Utilize one API for your authentication that won’t go through constant modifications, so you can spend more time focused on your own application.
- Customize security. The micro service allows for a range of customization to fine tune user session length, login policies, and more.
Implementing the services in your application
Most of the implementation details for the system will be provided with friendly software packages that perform most of the authentication logic. Unfortunately, these packages are not yet available and implementation is a manual process.
There are a number of different objects or models involved in a user’s authentication attempt.
AppToken – Generated by an administrator in the LCSR Identity Services management console. Proves that your application’s backend can use the system.
RequestToken – Generated by the LCSR Identity Services to facilitate an authentication request. Requested by an app’s backend using an AppToken.
Ticket – Generated by the LCSR Identity Services after a RequestToken has been fulfilled (i.e. it has passed a backend provider, like CAS). Repeatedly used by a user to prove authentication multiple times.
–
The “1000 foot overview” of the process: User wants to see something that requires authentication. Backend notices this and checks if the user has a Ticket session. They do not, so the app uses its AppToken to make a RequestToken. It sends the user, along with the RequestToken, to the LCSR Identity Services to complete authentication. The user completes authentication via a backend provider and is redirected back to the LCSR Identity Services. The system expires the RequestToken and issues a new Ticket for the user. The user is redirected back to the app’s backend alongside the Ticket. The app checks that the Ticket is valid and stores it in the user’s session. The backend redirects the user back to what they were originally trying to view. When this happens, the backend app checks if the user has a Ticket session. The user does, so the backend service checks that it is valid. Once the Ticket is validated, the user can see the content requiring authentication and the backend returns that content to the browser.
The below flow describes the process in more detail.
Using an existing client package
Client packages are available for common technologies and frameworks to allow for easy implementation of this LCSR micro service.
Right now, this service supports the following technologies out-of-the-box using an available package:
- Laravel (repo, access is restricted) – the package comes with a demonstration application that can be used to see how the system works. The included README describes how to add the package to any existing or new Laravel application.