Table of Contents
Advertisement
Security Concepts for Policy Manager
The authenticating authority is a key concept. The authority, which is usually a specific domain
controller in the enterprise, processes network authentication requests. Consequently, the
requesting computer must be both physically connected to that domain and recognized by it.
If the credentials are valid, i.e., they present the information required for the authenticating
authority to recognize a unique person (JSmith for instance), that person's network identity has
been established and he or she has been authenticated.
Policy Manager uses authentication in two places:
In all communications between clients (both the administration client and Intellex instruments) and
the server, COM+ and the underlying DCOM sub-system authenticate the current interactive
session on the client machine and then apply the result to authorize the user based on his/her role
assignments.
In all communications between a single Network Client workstation and an individual Intellex
instrument, explicit authentication is used at the instrument, based on the encrypted credentials
the client application sends it. This authentication process prompts creation of a Windows session
on the instrument. Authorization is then given using explicit access checks for each feature that
the client requests.
The Windows session
If a user's credentials have been processed successfully, a Windows session is created for the
user on the host computer. Rules are represented by a set of policies and permissions that Policy
Manager maintains for the entire site, as well as for each individual instrument. Applying the rules
on a per user basis is authorization.
Site policies and permissions
Policy Manager applies both general and specific rules. General rules are site policies that are
applied to all users who access the system, regardless of which instrument they may target.
Permissions are instrument-specific and comprise the core of Intellex advanced security. Each
instrument monitors and enforces the same set of permissions, such as Live Video. For example,
both Intellex1 and Intellex2 will monitor access to live video on camera 13, even though camera 13
may not exist. Together, these permissions comprise the security environment that controls and
protects the unit.
Although all instruments support and enforce the same set of permissions, permissions are
granted or denied per instrument and per user. For instance, if JSmith is an authenticated user, he
may be allowed to see live video on Intellex1, but not on Intellex2.
Consult your Intellex User's Guide for a more in-depth explanation of each permission or feature.
Authorization
In general, users want to access a specific Intellex unit and its features. As an administrator, you
(or someone else) may want to access the data stored on the server that describes your site. In
addition to access, you want to change the data. Consequently, both access to individual
instruments, as well as access to the server, must be controlled.
You control server access by using the pre-defined roles for the server application discussed
above. If access to a specific server feature is restricted (such as creating new zones), the user
making the request must be a member of the role that has access to that feature. In our example,
the user must be registered as a member of the 'Site Administrators' role.
Instrument access is controlled using the 'security environment' that applies to that instrument.
This means that the client has been authenticated and a valid Windows session has been created
on the target instrument.
30
Intellex® Policy Manager
Advertisement
Table of Contents
