Understanding how LUSID’s identity management and access control systems work

LUSID denies access to all resources for every user—whether human being or automated service, either via the web app or by calling the API directly—until explicitly allowed. 

LUSID has separate identity management and access control systems that work together to authenticate users and grant each the permissions they need to perform their professional responsibilities, and no more.

Identity management 

A user must supply valid authentication credentials in order to sign in to LUSID: 

• To sign in to the LUSID web app, a personal user must supply a valid username and password, and at least one multi-factor authentication (MFA) factor. An inactive user is signed out after one hour.
• To call the LUSID API, a service user must supply a valid username, password, client ID and client secret in order to obtain an API access token, which enables API calls for one hour. After this time, a new token is required.

For more information on these different types of user, and recommended best practice for which to use in different workflows, start with this article. To see how to onboard users into LUSID, work through this tutorial.

Access control

Even once authenticated, a user cannot access data or perform operations within LUSID until all access control checks have been performed. 

Every user must have at least one role assigned, and each role must have at least one policy (without a role and policy, a user has no rights at all). A policy is a grant or denial of access to either a particular entity dataset or to a particular feature (more on this difference below). For example, a user might have a policy that can be described as follows: 

Grant access to list all the portfolios in a particular scope, and thus to see transactions for those portfolios that have been added after a certain date. 

Or: 

Deny access to see quotes from a particular market data provider for certain instruments.

It's possible to compose policies at any level of granularity, to grant users just the permissions they need. LUSID provides some default roles and policies to get you started, and as the domain owner you are automatically assigned the built-in lusid-administrator role, which has the all-powerful full-access-to-all-resources policy collection. 

A note on terminology: In LUSID, an entity is a data structure. For example, a portfolio is an entity that stores transaction and corporate action data, from which holdings (positional data) can be calculated. A quote is an entity storing market pricing data. A portfolio group is an entity storing portfolio data, and so on.

Upon each access request, LUSID checks each policy in every role for the calling user, in the following order. Note if there are policy conflicts, roles have a precedence that determine which take effect:

1. First, LUSID checks a user’s feature policies. A feature policy allows (or denies) access to one or more API endpoints, for example to the ListPortfolios endpoint. Note this check is performed even for personal users using the LUSID web app, since the web app itself calls the API. If the user is permitted to use endpoint(s), then the check proceeds, otherwise the user is denied access.
    
2. Next, LUSID checks a user’s data policies. A data policy allows (or denies) access to one or more entity datasets, for example to portfolio data. Note a user might have permission to call the ListPortfolios API endpoint but not to see portfolio data returned by that endpoint (admittedly this might not make much sense). If the user is permitted access to (for example) portfolio data per se, then LUSID goes on to apply the first policy it finds that further restricts access to particular portfolios:
    
   • If LUSID finds a data policy that restricts access based on identifiers (see this table for different entities), it applies that policy. For example, a user might be restricted just to the portfolios in a particular scope, or just to a single portfolio as uniquely identified by its scope and code. Note not every entity supports restrictions based on identifiers; see the table below. Note also that such a policy may further restrict access based on dates, so that (for example) a user can only see transactions in a portfolio added after a certain point in time.
      
   • If LUSID finds a data policy that restricts access based on access metadata, it applies that policy. For example, a user might be restricted to just those portfolios explicitly allocated to them in portfolio metadata, and denied access to all others. Note not every entity supports restrictions based on access metadata; see the table below.
      
3. Finally, for each data policy, LUSID checks whether a user is permitted to access properties decorated onto entities that support properties (see the table below). For example, it’s possible to compose a data policy that permits access to all the core data for a portfolio, but only to see properties in a particular scope, or only to see properties added after a certain date, or to see all properties except one. By default, unless explicitly allowed, a user cannot see any properties.

If an access check fails and a user receives an ‘Access Denied’ error, you can use LUSID’s built-in troubleshooting service to diagnose the problem and, if appropriate, amend policies.

Support for data policy checks

Currently, not every entity supports all the data policy checks that LUSID is capable of making: