Announcing Record Level Security Preview for the Common Data Service

Today we are extremely pleased to announce the preview of record level security in the Common Data Service! With security policies, you can limit the data records that are returned to the user, reducing the need for application level restrictions. The ability to define record level security will expand on the entity level security that is available today via User roles.  We’ve heard from many users and customers that record level security is a critical part of the applications they’re building so we are bringing that to you now.

The Common Data Service uses a role-based security model to ensure users have proper access to data.  Access to a collection of data is granted within a permission set and a collection of permission sets can be associated with a role.  Users can then be assigned to a role and leverage all the data they are granted access to. For a more detailed description of the Common Data Service security model, refer to the Common Data Service Security Model document.

 

An Introduction to Security Policies

A security policy restricts a user’s access by placing a condition on one or more fields included in the record.  If the condition is met, then an action on the data can be performed. Separate policies can be defined for each data operation: Create, Read, Update, and Delete. This provides the flexibility to define the right data restrictions for every potential scenario.  For example, store employees should be able to see (read) all of the Products that are in the system, but only modify the ones that are active (and not delete any!).

We are announcing preview support for two types of record level security policies today, picklist based policies and principal based policies.  Security policies based on picklist allow you to define access based on the value of a picklist included in the record. For example, you can limit a list of customer accounts to only those accounts where the status is active.  Principal based policies are dependent on the principal, in most cases an end user, who is currently connected to the Common Data Service. For example, the list of customer accounts can be limited to only return those accounts where the current user is listed as the owner of the customer account.

 

Building a Security Policy

A security policy is comprised of three parts, the field the policy is tied to, the operator relating the field to a value, and the value the field must be compatible with. The structure of the preceding customer account example is shown below.

Field	Operator	Value
Account Status	Equals	Active
Account Owner	Equals	Current User

 

The combination of the operator and the value define the condition that must be passed for a record to be included. If a user attempts to get or interact with data from the Common Data Service and the value of the field matches the value in the condition, the check will pass and the user will be allowed to continue. If the check fails, the operation will be blocked.

The condition portion of a security policy (Operator + Value) only depends on the field type being compatible with the value defined in the policy. This allows the same policy to be reused with a field of the same type on the same or different entity. In our example, the Account Status policy could be applied on any entity where the Account Status picklist is used.

Record level security can be configured in the Security section of the Admin Center. Step by step instructions are included in the Configure Database Security article. Security configuration can also be done in code via the Common Data Service SDK.

 

How Policies are Combined

It is common for multiple record level security policies to be applied to a single request to the Common Data Service. To ensure the proper view of data, it is important to understand how multiple policies will be applied together.

Policies that are assigned to a single entity operation (Create, Read, Update, Delete) within the same permission set must all be met for a record to be returned. The policies are combined with a  logical AND inside of a permission set.

If multiple policies are set on the same entity in different permission sets, records will be returned if they pass only the policies defined in any of the individual permission sets. The policies are combined with a logical OR between permission sets.

 

How to Get Access to Preview Programs

The record level security features described in this blog are currently in preview. We want to make sure we get this solid before rolling out broadly. If you are interested in trying out this functionality and providing feedback, please join the Common Data Service preview programs! You can join the program by sending mail to cdspreviewprogs@microsoft.com.

 

Thanks!

Matthew