How Policies are defined and allocated to Roles to control access to entities and functionality in LUSID.
A Policy in LUSID provides the ability to specify whether one or more entities (or pieces of functionality) can - or explicitly cannot - be accessed. Policies are attached to (one or more) roles, to which users can be assigned. The policies attached to a user’s assigned roles are what decide what the user is, or is not, allowed to access when using LUSID.
A policy is composed of essentially three different logical parts: The meta data, the qualifying conditions and the grant.
The meta data refers to those properties on a policy that are used to describe it e.g. code, display name, description.
The qualifying conditions are those parts of a policy that must all be met in order for the “grant” to apply. A descriptive example of the conditions of a policy might be: “If the user is trying to READ any Portfolio in the scope Home with an effective date of 1st June 2019”. If the activity being performed by the user matches a policy’s qualifying conditions, then whether or not they will be permitted to perform the action will be dictated by the grant of the matching policy.
The grant is the ultimate decision of the policy - whether to ALLOW or explicitly DENY access. If any given role has two policies attached to it, one that grants or one the denies access, the deny will always be used.
In the absence of a policy that explicitly ALLOWs access, the default response will be to deny access to any data or functionality in LUSID.