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)

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.

Contents Next section Index