The Ed-Fi “Classic Dashboards” are no longer supported through the Ed-Fi Alliance. You can still receive support and maintenance through the Ed-Fi vendor community. Please look at any of the vendors’ dashboard solutions on the Registry of Ed-Fi Badges or the Ed-Fi Starter Kits if you are looking for a visualization solution to use with the Ed-Fi ODS. This documentation will remain available to assist existing Classic Dashboard implementers.

UI Developers' Guide - Security Overview

Owned by Itzel Torres
Apr 01, 2019
2 min read

This section provides an overview of authentication and authorization in the Ed-Fi Dashboards application.

Security Configuration Overview

Castle Windsor is used as the dependency injection engine throughout the dashboard application. Castle Windsor configuration begins in the Application_Start method of the Global.asax.cs file. An InversionOfControlContainerFactory is created which reads from a configuration file to locate appropriate installer (IWindsorInstaller) class names. Each of these installers is given the opportunity to register classes within the Windsor container.

Configuration-specific configuration classes inherit from ConfigurationSpecificInstallerBase and are located in the Utilities/CastleWindsor subdirectories of the particular project in question. The registration methods of the appropriate configuration class are called from a RegistrationMethodsInstallerBase descendant (in EdFi.Dashboards.Common) which is a concrete implementation of IWindsorInstaller.  

Authentication Overview

Authentication schemes are responsible for determining the identity of a user. The Ed-Fi Dashboards application is configured to use federated authentication. The configured source for federated authentication is the EdFi.Dashboards.SecurityTokenService.Web web project. The SecurityTokenWebService website uses the MVP pattern behind its Login.aspx page.

Any of the provided (or custom) authentication providers (i.e., implementations of IAuthenticationProvider) may be used, but the core code distribution is configured to use the AlwaysValidAuthenticationProvider (located in EdFi.Dashboards.Resources.Security) by default. This provider is the default provider because it simplifies the work for developers to get up and running on a development machine.

The AlwaysValidAuthenticationProvider allows any user name to login with any password, which does make development easy but is, of course, not suitable for a production application. The provided user name is used for authorization.

A good place to get started with the integration patterns required for a more robust security model is by using File-Based Authentication discussed in the next section.

Authorization Overview

Authorization schemes are responsible for determining what a user is allowed to do in a given context. In the default configuration of the as-shipped code distribution, the AuthorizationInformationProvider (in EdFi.Dashboards.Resources.Security.Implementations) is used to determine the district, school, classroom, and student privileges that are accessible to each specific authorized user. Claims are compiled with the assistance of the DashboardDatabaseWithStateAgencySupportUserClaimsProvider or its ancestor DashboardUserClaimsProvider (both in EdFi.Dashboards.Resources.Security.Implementations).

See the Claims-Based Authorization section for more detail.