Summary of Dataworks Enterprise Permissions System

This article briefly outlines the functionality of permissioning with in the cache.

In Dataworks Enterprise permissioning system access restrictions are implemented at three levels: source, record and field. At source level we can control whether a user can see or use a source. In addition, through the use of aliases, we can, on a per user, basis redirect requests to different sources. Record level permissioning controls if a user can access a record or not, and field permissioning controls access to the individual data items within a record.

When a user first interacts with the cache, a request is made to a permissions source, which returns an image containing the users entitlements. The entitlements comprises an array of source names, permission flags, aliases and information necessary to apply record and field filtering. The permission flag will indicate whether access to a source is denied, restricted or unrestricted. Where a source is denied it will not be visible to the user and attempts to bind a record to this source result in an �Access Denied� error. In the case of unrestricted sources, no permissioning will not be enforced. Restricted, the default, means that if the record contains permissions information it will be examined and used as the basis of record and field filtering. If an alias exists, a source will be exposed to the user using a pseudonym.

The user's entitlements contains a collection of authorities. For each authority there will be list of Product Ids. The record permissions will be evaluated against this set and access granted or denied as appropriate. Associated with each product, there may be field entitlements.

It is the responsibility of a source to populate the permissions information associated with the record. In doing so it advertises its self as permissioned.

Where no permission server is available, a client will be able to direct requests to all sources but only receive valid responses if the images do not contain permissions information. In the future it might be useful to modify this behaviour with an encrypted configuration file or registry entry residing on the client machine.

There are two modes of authentication supported, trusted and server side. In trusted mode the OS user associated with the thread creating the connection to the cache will be used to retrieve the user's entitlements. With server side authentication the user creates an "principal" object, sets the user and password properties and attaches this to an existing connection to the cache. The attachment must occur before any method causing client/cache interaction. (e.g. getting data or a list of sources).

A source may, on a per field, basis indicate a "category" known as AuthInfo. This is a value that indicates (for the purposes of permissioning) what kind of data the field contains. For example, this might be used to indicate that the field is Level2 dta, or put another way, that the user must have entitlements to Level2 data to access the field. This can also be used to represent real-time, delayed or fundamental permissions. This AuthInfo is used in association with the authority and product information contained in the permissions structure to apply field filtering. For any given field there are 15 such values available to the source (0 is always taken to mean no filtering). When AuthInfo is applied, the cache removes the last three characters of the field name from the field. This is to allow records to carry multiple fields with different AuthInfo values (such as real-time LAST_RT and delayed LAST_DL) and, automatically, rename to LAST from the user's perspective.