This version of the Ed-Fi ODS / API is no longer supported. See the Ed-Fi Technology Version Index for a link to the latest version.

 

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Security settings for the Ed-Fi ODS / API are stored in two separate databases, EdFi_Admin and EdFi_Security. Both databases are required. The EdFi_Admin database stores security configurations specific to an instance of the Ed-Fi ODS / API. The EdFi_Security database also stores security settings for the ODS / API, but in a more general format intended for use by other Ed-Fi applications. Said another way, the EdFi_Admin database belongs to the ODS / API, while the EdFi_Security database stores security settings for multiple Ed-Fi applications, of which only one is the ODS / API.

Ed-Fi Admin Database

The EdFi_Admin database stores the following configuration entities:

  • Vendors. Each education software vendor is represented in the admin database and serves as a wrapper for individual users and applications. Vendor records include a namespace prefix, which takes the form of the URL for the vendor's website. The namespace prefix is used by the claims system where callers need to manage their own data. 
  • Vendor Users. Each vendor may have one or more users defined. The database includes the full name and e-mail address for each user for identification purposes.
  • Vendor Applications. A list of applications supported by education software vendors on behalf of one or more education organization (specifically, an LEA such as a district, or a school). A single application may be associated with more than one education organization or a separate vendor application record can be created for each education organization. In addition, each vendor application is assigned a claim set, defined in the Ed-Fi Security database, which defines its level of access.
  • API Clients. Each API client record references a vendor user and application. In addition, each API client record may be reused between vendor application-LEA combinations, or be uniquely defined for each vendor application to education organization association. Finally, each API client record includes both a key and a secret, which function as a public and private key for the Ed-Fi ODS / API, respectively.

The following entity relationship diagram (ERD) provides additional data on the structure of the EdFi_Admin database:

Ed-Fi Security Database

The EdFi_Security database stores information about available resource claims and their relationship to claim sets, Ed-Fi applications, and authorization strategies. The following high-level entity descriptions provide additional context:

  • Ed-Fi Applications. Distinct Ed-Fi applications that require access to resources within an education agency’s Ed-Fi technology implementation. Currently, there is only one record in this table, representing the ODS / API itself.
  • Resource Claims. Each resource exposed via the ODS / API interface will have a record in the resource claim table. Access to these resources is controlled by their inclusion in claim sets and their associated authorization strategies. Resource claims are organized as a hierarchy, so that a set of related resource claims can be included in a claim set by referencing just the parent claim.
  • Resource Claim Sets. A claim set is a collection of resource claims for a common type of API client, such as that of a SIS vendor. Claim sets are created for convenience so that vendor applications do not have to be individually associated to resource claims. A resource claim can belong to multiple claim sets.
  • Resource Claim-Authorization Strategy. Access to each resource claim will be granted through at least one resource claim-authorization strategy. A resource claim-authorization strategy combines a resource claim with additional logic, an authorization strategy, to validate the claim. For example, one available authorization strategy ensures that a vendor has access to all related entities before granting access to the requested resource while another requires no additional authorization. In addition, a resource claim-authorization strategy pertains to an available action: Create, Read, Update, Delete.
  • Actions: Each action (Create, Read, Update, Delete) is included as a record in the action table for reference by resource claim-authorization strategies.

The following ERD further outlines the entities and entity relationships in the EdFi_Security database:

  • No labels