Previous section.
Application Instrumentation and Control (AIC) API, Version 1.0
Copyright © 1999 The Open Group
AIC Security
Security Component
The security component implements all functions necessary for a given
security model/package. The component can contain functions for both
a client and the security server (service), although this is matter
for specific implementations to address. This file is assumed to be
secure under operating systems security in order to prevent
unauthorised replacement.
With a shared library implementation this means different customers can
swap security implementations by swapping the library (component).
Figure: Security Plug-In Architecture
The real security offered by the component approach is dependent upon
implementation. For example, use of configuration files requires
security of those files.
This security model is based on the assumption that communication from
the AIC Security Host Service to the application is secure (within a
machine), but not secure from the client library.
AIC Client Library (AIC-CL)
The CL needs to send credentials (information on the client) in the
client library in the data transport message so the service can perform
the checks. The client component must match that used by the security
service. The component is responsible on the CL for collecting the
credentials, doing basic error checking, and then preparing them to be
sent securely within a data transport message (which will also contain
the command to be executed).
AIC Host Service: Security Component (Swappable Module)
The service has the same or a similar component to the one described
for the CL (and the same comments on the security of that plug in apply
here). In addition it will have two other functions - one checks for
authentication of the credentials, and the other checks for suitable
authority.
The authentication component takes the security package (which it
will decode) and then performs the authentication check. Should this be
successful, the next check is that the authenticated user is authorized
to perform the requested operation.
This is based on the idea that a person has "level x security" for a given
object.
Security Authorization Overview
Authorization is based on a security model independent scheme called
"levels". Authentication is performed by the security system being
used.
These are defined as follows:
-
-
Level 1 also passes Level 2-5
Level 2 also passes Levels 3-5
Level 3 also passes Level 4-5
Level 4 also passes Level 5
Level 5
Level 6 (unique)
Denied
None
Level 1 is for a super user, and has Levels 2-5 (that is,
passes any check for level 1-5).
Level 6 is for some unique potential action.
"Denied" means that operation on that object is denied (for example,
set
operations and
DoActions).
"None" means the operation is automatically allowed.
This model is implemented as an enumerated list:
{level1, level2, level3, level4, level5, level6, none, denied}
The security is set within an object - see the property "security"
within an object.
Semantics of Security Checks
The semantics for different types of security checks are presented
in the folowing table.
| Operation
| Result of Security Check
| Behavior
|
|---|
| Any
| FAIL
| Error returned
|
| Single property get
| PASS
| Single object returned
|
| Single property set
| PASS
| Single object changed
|
| DoAction (set)
| PASS
| Function is called
|
| Multi-value get
| Authentication PASS.
Authorization per object:
Some PASS, Some FAIL
| All objects which PASS are returned. Objects which fail are omitted (as if hidden)
|
Table: Semantics of Security Checks
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.