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.Summary of Dataworks Enterprise Permissions
System
This article briefly outlines the functionality of permissioning with in the
cache.