How field security can be used to control access to field values in Microsoft Dynamics 365

Artykuł
11/28/2016

Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

In Microsoft Dynamics 365 and Microsoft Dynamics 365 (online), you use field-level security to restrict access to high business impact fields to specific users and teams. For example, you use this to enable only certain users to read or update the credit score for a customer. For this release, field-level security can be applied to both custom fields and many out-of-box (OOB) fields.

The following steps describe how to restrict access to a field:

Enable field-level security for an attribute
Create a field-level security profile
Associate users or teams with the profile
Add specific field permissions, such as Create, Update or Read for a specific attribute to the profile

The following diagram shows the interaction between role-based security, record-based security, and field-level security.

Role-based compared to field-level security

Role-based security lets you see a specific entity type, record-based security lets you see individual records, and field-level security lets you see specific fields.

Video: Field Level Security in Microsoft Dynamics CRM 2015

Frequently asked questions

Which attributes can be secured?
Which security roles allow you to see secured fields?
How do secured fields behave for Retrieve and RetrieveMultiple?
How do secured fields behave for create or update?
How do secured fields behave when records are shared?
How do secured fields behave for filtered views?
How do secured fields behave for offline synchronization?

Which attributes can be secured?

To see which attributes can be secured, you can query the entity metadata for the following properties:

There are thousands of attributes that can be secured, so there are two easier ways to look for this information. To view the entity metadata for your organization, install the Metadata Browser solution described in Browse the metadata for your organization. You can also view the metadata for an uncustomized organization in the Excel file called EntityMetadata.xlsx included in the top-level folder of the SDK download.

There are a few additional rules that apply to certain attribute data types:

Boolean attributes can be secured for create and update operations but not for read.
Option set attributes can be secured for create, update, and read when a default value is unspecified.

Which security roles allow you to see secured fields?

The System Administrator field security profile gives full access to all secured fields in Microsoft Dynamics 365. By default, all users who have the System Administrator security role have this profile. This profile is system managed and can’t be updated or deleted.

How do secured fields behave for Retrieve and RetrieveMultiple?

When you call the Retrieve or RetrieveMultiple methods or messages, Microsoft Dynamics 365 evaluates if the caller and the impersonated user have access to each retrieved record (this is the regular security process) and each secured field. The call does not throw an exception if the criteria contain secured fields for which the caller does not have access. Instead, null values are returned for secured fields if they are part of the output column set.

The following describes more about the retrieve multiple behaviors for secured fields.

When a secured attribute is in the column set

If the caller (or impersonated user) does not have read access to the secured fields that are included in a column set, the value returns as null. You cannot tell the difference between a returned null value caused by no data or caused by insufficient access.

When a secured attribute is in the filter condition

If the caller (or impersonated user) does not have access to the secured fields that are included in the filter criteria, the field value is substituted with null during the evaluation of the filter.

In the following table, the caller has access to all attributes except those indicated with an asterisk (*).

Record Number	Value of the Name attribute	Value of the Description attribute	Value of the Can Be Contacted attribute
1	A	AAA	True
2	B	BBB	False
3	C	CCC	True*
4	D	DDD	Null
5*	E*	EEE*	Null*

When the filter is CanbeContacted == True, only record one is returned.

When the filter is IsNULL (CanbeContacted), records 3 and 4 are returned. Since record 3 is hidden from the user, it is treated as null during condition evaluation and will be evaluated as True for ISNull.

When aggregating on secured attributes

Secured values are substituted with a null value, so normal SQL aggregation behavior applies.

When grouping on secured attributes

If the caller (or impersonated user) does not have access to the attribute used for grouping, the value is treated as null and the results are grouped together with all null values.

In the following example, the caller has access to some attributes. Bold indicates no access to attributes, also indicated with *. Italics indicate a record for which the caller does not have read access, also indicated with **.

Name	Description	Number of orders	State
A	AAA	1	WA
B	BBB	4	WA
C	CCC	4	CA
D**	DDD**	3**	MA**
E	EEE	0	CA
F	FFF	0	WA*
G	GGG	2	CA*

Select State, Total(orders) Group by (STATE) results in the following:

WA–5

CA–4

null–2

When ordering on secured attributes

If the caller (or impersonated user) does not have access to secured fields that are included in an order by condition, the values will be treated as if they are null.

In the following example, the caller has access to attributes that are in plain text. Bold indicates no access to attributes, also indicated with an asterisk (*). Italics indicate a record for which the caller does not have read access, also indicated with **.

Name	Description	CanbeContacted
A	AAA	True
B	BBB	False
C	CCC*	True*
D	DDD	Null
E	EEE*	Null*
F**	FFF**	True**
G	Null	True

Select Name order by Description ascending results in the following:

{G,E,C},A, B, D, will be returned.

How do secured fields behave for create or update?

A programmer may build a client that uses Create and Update methods that interact with secured fields. When you call the Create or Update method, passing data for secured fields and the caller does not have sufficient permissions, an exception is thrown.

How do secured fields behave when records are shared?

A user with access to a secured field in a record can share it with another user or team. The user can only give the access that they have on the record. For example, to share the record and grant Update privileges, the user must have update privileges.

You can share a secured field on a particular record with Read and/or Update with a security principal (user or team). The user or team members with whom the record was shared now have that type of secured field access only on the shared secured fields on only that particular record, even if the user or team member to whom it was shared does not have a field security profile that gives them access.

How do secured fields behave for filtered views?

An administrator secures a number of fields for access in the application and wants the fields not to be available in reports. This allows for maintaining the same set of reports for all users. Filtered views will not return data for the secured fields if the calling user does not have authorization for the fields. When no field security is applied for any of the view’s attributes, the filtered views return complete data.

How do secured fields behave for offline synchronization?

If you are using Microsoft Dynamics 365 for Microsoft Office Outlook with Offline Access, only the secured field values that you have access to replicate into the offline database. If you don’t have access to the data, it is not saved offline.

Udostępnij za pośrednictwem