DRAFT
Overview
| Info | ||
|---|---|---|
| ||
This Single-Sign On design document is in draft status and evolving as informed by the Ed-Fi community. Please use the Comments section below for any feedback into the design of single-sign on support for Ed-Fi Tools. If this design appears to fit the majority of Ed-Fi community need, the design will first be implemented in Admin App, then look to implement in Data Import as sharing similar needs and technology sets. |
Overview
The Ed-Fi Alliance provides Admin App as a user interface to manage the ODS / API Platform. Today, Admin App supports only forms-based authentication for using the application. The Ed-Fi community has signaled the strong need for providing a simple single-on (SSO) experience for numerous Ed-Fi Tools (such as Admin App and Data Import). The community has also identified Open ID Connect 1.0 as an common interface available in education environments, which then connects to existing identity stores, both open-source and from major provides such as Microsoft, Google and others.
This design proposes adding another a method of delegating user-authentication to trusted 3rd party-sources via OpenID Connect 1.0, to provide single-sign on like experiences to users of Ed-Fi tools. If this design, implemented code and pattern is successful in Admin App, it will be considered for reuse in applications such as Data Import. Implementation of this method builds upon the Ed-Fi Alliance's investment in .NET Core migration, which guidance is provided on implementing SSO patterns in this MSDN article: "Facebook, Google, and external provider authentication in ASP.NET Core".
Below is a table of contents for topics into the Single-Sign On design:
Table of Contents minLevel 2
Use Cases
This feature is targeted towards the IT administrator of an Ed-Fi Tech Suite and responsible for its secure operation. The IT administrator would like to use a trusted, 3rd party source as the source of identity for their users, instead of the built-in forms authentication available today.
Technical Details
Below are technical details related to the design of delegating authority to trusted 3rd parties within the Ed-Fi tools ecosystem.
Registering client application with external authentication providers
Client application needs to be registered to an external authentication provider, in order to delegate the user authentication process.
The client application registration varies across different providers.
Ex: Steps for registering Admin App to Google authentication provider API:
- Register Admin App with Google at https://console.developers.google.com
- Set the redirect URI to https://localhost:5000/signin-google (localhost:5000 will be replaced with Admin App host and port)
- User can get Client Key and Client Secret by setting up Credentials details on Google API
- User will be using the given Client Key and Client Secret on Admin App to establish the connection with Google API for authenticating the user
Note: Similarly, Admin App should be registered with custom OIDC authentication provider for availing client_key and client_secret.
Store external authentication provider details
For enabling OIDC authentication Admin App needs provider details, which includes OIDC server authentication Url, Client_Id, Client_Secret, ResponseType, and required scopes.
On development environment all these details can be stored on Authentication section on appsettings.json file or can be set as user-secrets.
ex: dotnetuser-secrets set "Authentication:Google:Client_Id""sampleapp"
For production environment, it is recommended to store Client_Id and Client_Secret on environment variables.
OIDC authentication flow on Admin App
Login flow
If OIDC/ external authentication enabled on Admin App! on Login page user will find form authentication controls as well as link/ button to OIDC authentication.
If user chooses to go with OIDC method, then user will be taken to third party confirmation page for signing in.
Upon successful sign in, session cookie will be set, and user will be navigated/ redirected to Admin App page.
Registering external user on Admin App
Registering external user on Admin App will make sure that user info, claims from external provider and
Admin App specific role details are getting added to Admin App authentication tables for future reference.
Log out
On Admin App, the cookie is used as default sign-in and sign-out schema. So, logout operation will clear the cookie.
Open Questions
1.) Does this design cover the majority of SSO/3rd party authentication needs?
2.) Is authentication one or the other? Or do we keep forms-based for first admin, then delegate the rest?
3.) Is configuration in UI or appSettings.json?
4.) Does Open ID Connect 1.0 provide for roles? We have two roles in Admin App - admin and super-admin. Can OIDC map to this?