共用方式為

Business Data Connectivity Service Authorization

  • 發行項

Applies to: SharePoint Server 2010

In this article
Back-End Authorization
Middle-Tier Authorization
Back-End Authorization with UserContextFilter
Access-Controlled and Individually Securable Metadata Objects
Summary of Rights

You can use either of two authorization patterns to control user access to data managed by the Microsoft Business Connectivity Services (BCS): back-end authorization or middle-tier authorization.

Back-End Authorization

If your back-end server can perform per-user authorization, you can use back-end authorization to control user access. You can use back-end authorization in the following situations:

  • You are using the Impersonation and Delegation model for authentication, and there is per-user authorization at the back-end server. In the Impersonation and Delegation model, the client delegates authentication to the middle tier, which impersonates the client and authenticates to the back-end server on the client's behalf. However, if the back-end server does not support per-user authorization, you might have to use the other authorization mechanism described in this topic.

  • The back-end server supports per-user authorization, and you are using application-level authorization, passing the user name in the Username filter.

  • The back-end server offers connection pooling or other performance benefits.

Middle-Tier Authorization

In the Trusted Subsystem authentication model, the middle tier authenticates to the back-end server as a fixed identity, and the back-end server never knows the user's identity. Therefore, if you use this authentication model, you cannot use back-end authorization, even if the back-end server supports per-user authorization, because the server cannot authorize each user.

In such cases, use the middle-tier authorization of Business Data Connectivity (BDC) service instead. BDC is designed to perform per-user authorization in the middle tier. This authorization model offers the following benefits:

  • Database connection pooling.

  • A single model for authorization.

  • Support for scenarios in which there is no per-user authorization at the back-end server.

  • Granular access control. BDC enables you to set access control lists (ACLs) at the following levels:

    • MetadataCatalog   This is the top-level object in BDC, which controls who can import models to or export models from BDC.

    • LobSystem

    • Entity

    • Method

    • MethodInstance

    In addition, you can have different views of the entities in BDC. Therefore, you can control the fields a user can view.

Back-End Authorization with UserContextFilter

The UserContextFilter filter tells BDC to add the current user's name to the back-end method call. The back-end method can then use the user name to check the user's access or to limit the entity instances returned from the back-end server by the current user's context.

This is especially useful when back-end applications do not have authorization information or do not use it because of licensing or connection pooling reasons. In such cases, they can use a group account to authenticate and use the passed-in user name to determine and control access to data.

Another scenario for using a UserContext filter might be if a metadata author creates metadata that takes a user name as a user-controllable filter, and returns sensitive personal data; in this case a user might see another user's data. To avoid this, you can use the UserContext filter to pass in the user name to the method call.

Note

The UserContext filter is secure and the filter value cannot be overridden.

For Windows users, BDC passes the System.Security.Principal.WindowsPrincipal.Identity property in the format domainname\username.

Access-Controlled and Individually Securable Metadata Objects

Each object in the BDC hierarchy of metadata objects (Application, Entity, Method, MethodInstance, Parameter, TypeDescriptor, and so on) has an ACL that specifies which principals have which rights on the object. Of the 13 metadata objects, only LobSystem, Entity, Method, and MethodInstance have their own individually controllable ACL. These objects are known as individually securable metadata objects. Other metadata objects inherit the ACL from their immediate parent and are known as access-controlled metadata objects.

Summary of Rights

The following table shows the rights the administrator or someone with the Manage Permissions right can set on a BDC application.

Important

After changing users' permissions in the BDC, you must run the crawl again for them to be able to search business data. This is because ACLs are crawled with the data and therefore will be out of date if you change them.

Table 1. Summary of rights that can be set on a BDC application

Right

Applies To

Description

Edit

Access-controlled metadata objects

  • Update the object

  • Delete the object

  • Create child object

  • Add property

  • Remove property

  • Clear properties

  • Add localized display name

  • Remove localized display name

  • Clear localized display names

Set Permissions

Individually securable metadata objects

  • Set permissions

  • Copy permissions to children

Execute (View)

MethodInstance

  • Execute the MethodInstance object via various run-time API calls

Selectable in Clients

Application and Entity

  • Use in Web Parts and lists

  • View in Picker