Epic: Add Support for Authorizing API Requests with Multiple Authorization Strategies 

Story: Add database support for storing metadata for multiple authorization strategies

As an API host, I want to be able to define authorization metadata needed to be able to apply multiple authorization strategies to API client requests so that I can implement ownership based security.

Description

Currently, the schema of the EdFi_Security database only allows for a single authorization strategy to be assigned to a particular resource claim / action combination (or claim set-specific override).

The schema must be enhanced to allow the application of multiple authorization strategies.

Tasks

• Create a database migration script (with corresponding entity changes) that renames existing columns and tables as follows:
  • Rename the ResourceClaimAuthorizationMetadatas table to ResourceClaimActionAuthorizations.
  • Rename the primary key column of the ResourceClaimActionAuthorizations table from ResourceClaimAuthorizationStrategyId to ResourceClaimActionAuthorizationId
  • Create unique constraint/index on the ResourceClaim_ResourceClaimId and Action_ActionId columns.
  • Ensure that all related artifacts (i.e. FK constraint names) are named correctly to prevent future EF migration failures.
  • Create and preserve a single commit inclusive of the changes to entities and the associated migrations (do not squash the commit).

• Create a database migration script (with corresponding entity changes) that renames existing columns and tables as follows:
  • Rename the ClaimSetResourceClaims table to ClaimSetResourceClaimActionAuthorizations.
  • Rename the primary key of that table from ClaimSetResourceClaimId to ClaimSetResourceClaimActionAuthorizationId.
  • Create unique constraint/index on the ClaimSet_ClaimSetId, ResourceClaim_ResourceClaimId and Action_ActionId columns.
  • Ensure that all related artifacts (i.e. FK constraint names) are named correctly (partly for consistency, and partly to prevent future EF migration failures depending on the timing of that conversion).
  • Create and preserve a single commit inclusive of the changes to entities and the associated migrations (and do not squash the commit).

• Create a database migration script (with corresponding entity changes) that drops existing FKs and Indexes and moves the AuthorizationStrategyId FKs to new child tables (ResourceClaimActionAuthorizationStrategies and ClaimSetResourceClaimActionAuthorizationStrategyOverrides).
  
  
  
  
  • Create primary key columns as ResourceClaimActionAuthorizationStrategyId and ClaimSetResourceClaimActionAuthorizationStrategyOverrideId, respectively.
  • Create unique constraint/index on the FK columns of new child tables, as follows (respectively):
    • ResourceClaimActionAuthorization_ResourceClaimActionAuthorizationIdId, and AuthorizationStrategy_AuthorizationStrategyId columns.
    • ClaimSetResourceClaimActionAuthorization_ClaimSetResourceClaimActionAuthorizationIdId, and AuthorizationStrategy_AuthorizationStrategyId columns.
  • Data migration must also move existing inline authorization strategy assignments to the child tables.

NOTE: An incomplete version of this script generated using the SSMS database diagram designer after producing the images above is attached here for reference. See EdFi_Security--Add-support-for-multiple-authorization-strategies.sql.

Story: Modify API to surface multiple authorization strategies in the metadata to the authorization components

As an API host, I want to make multiple authorization strategies defined in the security database available to the components that perform authorization so that the authorization system can apply them to the database requests appropriately.

Description

The authorization subsystem has several components involved in ferrying the pertinent authorization metadata from the security database to the components that apply the necessary data/operation filtering to incoming API requests. This story will make the changes necessary to support carrying the new metadata for multiple authorizations to the components that perform the authorization (without actually affecting existing functionality).

To facilitate this work, a spike branch has been made available in the Ed-Fi-ODS repository on GitHub (spike-Ownership-based-authorization). While the code in this branch has been not tested at all, it shows the essence of the changes necessary.

Tasks

• Adjust the artifacts that currently reference authorization strategy names (or overrides) in the singular as type string  to IReadOnlyList<string> (except for the EF security model entities which should use List<string> ):
  • ~\Ed-Fi-ODS\Application\EdFi.Ods.Common\Security\Claims\EdFiResourceClaimValue.cs
  • ~\Ed-Fi-ODS\Application\EdFi.Ods.Common\Security\Claims\IResourceAuthorizationMetadataProvider.cs
  • ~\Ed-Fi-ODS\Application\EdFi.Ods.Security\Authorization\EdFiAuthorizationProvider.cs
  • ~\Ed-Fi-ODS\Application\EdFi.Ods.Security\AuthorizationStrategies\ResourceAuthorizationMetadataProvider.cs
  • ~\Ed-Fi-ODS\Application\EdFi.Ods.Security\Claims\ClaimsIdentityProvider.cs
• Modify the CreateEntity and CreateEntityAuthorizationDecorator classes to use a single generic type constraint of AggregateRootWithCompositeKey.
• Update any other classes impacted by changes itemized above. Refer to the spike branch for additional guidance.

Story: Authorize API Requests Based on Resource Ownership

As an API host, I want to apply ownership-based authorization strategy in addition to relationship based authorization so that API clients are constrained as they are today but cannot modify data created by another API client.

Description

The current authorization system already appears to apply multiple filter criteria, so it appears that the code base merely needs the additional of a couple of classes in order to perform the appropriate authorization.

NOTE: All implementations of INHibernateFilterConfigurator  and IEdFiAuthorizationStrategy  are located and registered automatically by the AuthorizationStrategiesInstaller, so no additional container registration logic should be needed.

Tasks

• Implement a filter configurator (OwnershipBasedAuthorizationStrategyFilterConfigurator)for ownership based authorization
  • The class should implement the INHibernateFilterConfigurator interface using the NamespaceBasedAuthorizationStrategyFilterConfigurator as a reference.
  • When defining the criteriaApplicator  action delegate, make use of the ICriteria extension method ApplyPropertyFilters to apply the necessary criteria.
• Implement an authorization strategy (OwnershipBasedAuthorizationStrategy) for ownership-based authorization
  • The class should implement the IEdFiAuthorizationStrategy  using the NamespaceBasedAuthorizationStrategy  as a reference.
  • Named parameter value (CreatedByOwnershipTokenId) should be assigned from the client's claims (OwnershipTokenIds) as an array of objects.