Share via

Business Data Catalog Authorization

  • Article

You can use either of two authorization patterns to control user access to data managed by the Business Data Catalog: 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 one of the other authorization mechanisms described later 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 Business Data Catalog middle-tier authorization instead. The Business Data Catalog is designed to perform per-user authorization in the middle tier. This authorization model has the following benefits:

  • Offers database connection pooling.

  • Provides a single model for authorization.

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

  • Provides granular access control. The Business Data Catalog allows you to set access control lists (ACLs) at the following levels:

    • Application Registry   This is the top-level object in the Business Data Catalog, which controls who can import or export application definitions into the Business Data Catalog.

    • LobSystem

    • Entity

    • Method

    • MethodInstance

    In addition, you can have different views of the entities in the Business Data Catalog, and therefore, you can control the fields a user can view.

Back-End Authorization with UserContextFilter

The UserContextFilter filter tells the Business Data Catalog 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 particularly useful when back-end applications do not have authorization information or do not use it due to 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 cas 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 Microsoft Windows users, the Business Data Catalog passes the System.Security.Principal.WindowsPrincipal.Identity property in the format domainname\username. For Web clients, the Business Data Catalog passes the System.Web.HttpContext.Current.User property.

Access-Controlled and Individually Securable Metadata Objects

Each object in the Business Data Catalog 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 referred to as Individually Securable metadata objects. Other metadata objects inherit the ACL from their immediate parent and are referred to 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 Business Data Catalog application.

Important

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

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

Manage 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

See Also

Tasks

How to: Add an Access Control Entry to a Metadata Object
How to: Get the Access Control List for a Metadata Object

Concepts

Business Data Catalog Authentication