RE: Is this topic dead?

[[e-mail]]

Nick,

> Has there been any interest in progressing the proposed API?  Has 
> anyone produced any proposals?  Or is this activity likely to drop into 
> oblivion.

I think that there is interest, but other work items have higher 
priority ...

The official status (from the SAAG minutes):
    *    wi029: Authorization and Access Control WG (Updated 04/94)
         The authorization and access control draft that exists
         will be revised and get a final working group review in Toronto 
         before being submitted for publication as an informational
         document.  At that time the charter
         of this working group will be revised.
         
 
> If there are any proposed API specifications can someone give me a FTP 
> reference.

See the Houston minutes which summarise discussions to date. These
were posted to the list and are available on-line and in the 
proceedings


I have been looking at this area in the context of another project. I
was holding off posting until I had an implementation which was
suitable for wider distribution, however since you asked I would
be interested in any comments you (or others) have on the following

Piers


---
              ACCESS DECISION FUNCTION

                        23MAY94

                          pvm


1. Summary

In support of the goal of a generic access decision function 
interface, this paper discusses related work in XDSF (POSIX.22), 
POSIX.6, and DCE, and then proposes a portability model (as 
considered in IETF AAC).



2. References

The following are referenced by this paper:

[POSIX.6]     Protection, Audit, and Control Interfaces P1003.1e,
              draft 14, MAR94

[DCE-ACL]     DCE RFC 46, OCT93

[XDSF V3]     XDSF Version 3  --  P1003.22 D3

[ISO-AC] ISO Access Control Framework

[Ex-GSS] An Extended Generic Security Service API, Ses/Paper/010,
              Issue 5, 25JAN94



3. XDSF

XDSF section 4.3 defines a model for access control based on the ISO 
access control framework.

A number of services are identified, namely:

*   Access decision function
    - Decide Access (based on initiator, target, and required action)
    
*   Management Services
    - Install ACI 
    - Modify ACI
    - Revoke ACI
    - List ACI
    - Disable Component (i.e. ADF)
    - Re-enable Component (i.e. ADF)

*   Other Operational Services
    - Acquire Initiator ADI
    - Acquire Target ADI
    - Generate Data ADI
    - Generate Action ADI
    - Revoke ADI
    - Verify Action ADI
    - Get Contextual Information
    - Bind Initiator ADI
    - Retrieve Initiator ADI

The "other operational services" are given in abstract terms, and 
while some of likely to be of concern to application developers,  
others are of concern to mechanism-providers.  It would be helpful 
to develop the operational model more completely.



4. POSIX.6

POSIX.6 defines an ACL (access control list) facility for POSIX.1 
files which serves to extend the existing POSIX.1 discretionary 
access control.

The draft standard defines
- basic concepts:
  + ACL semantics (though not the internal respresentation),
  + ACLEs (i.e.: ACL entries)
  + ACLE tag type, and the standard POSIX.6 types (ACL_USER,
    ACL_GROUP, ACL_GROUP_OBJ, ACL_USER, ACL_USER_OBJ, ACL_OTHER_OBJ)
  + ACLE qualifier, and its definition for ACL_USER and ACL_GROUP
  + [ACLE] permission set
- the algorithm for evaluating ACLs,
- rules and functions for the association of ACLs with objects,
- functions for manipulating ACLs, and
- functions for ACL import/export in text and (implementation-
  defined) binary format.

POSIX.6 functions are defined to:
- manage the ACL working storage area
- manipulate ACLEs
- manipulate fields within ACL entries
- read/write an ACL on an object
- translate an ACL into different formats

POSIX.6 functions to manage the ACL working storage area
- acl_dup                    duplicate ACL data object
- acl_free                   release ACL memory data object
- acl_init                   allocate/initialise ACL data object

POSIX.6 functions to manipulate ACL entries
- acl_copy_entry        copies between ACLEs
- acl_create_entry      create ACLE
- acl_delete_entry      delete ACLE
- acl_first_entry       goto 1st ACLE (start of ACL staorage area)
- acl_get_entry              get ACLE descriptor
- acl_valid                  report duplicate, missing, ill-formed ACLEs

POSIX.6 functions to manipulate fields in an ACL entries
- acl_add_perm               add permission to permission set
- acl_calc_mask              initialise ACL_MASK ACLE
- acl_check_perm        check permission in permission set
- acl_clear_perm        check all permissions in permission set
- acl_delete_perm       delete a permissions in permission set
- acl_get_qualifier          get ACLE qualifier
- acl_get_tag_type      get ACLE tag type
- acl_acl_set_permset   get ACLE permission set
- acl_set_qualifier          set ACLE qualifier
- acl_set_tag_type      set ACLE tag type

POSIX.6 functions to read/write an ACL on an object
- acl_delete_def_fd          delete default ACL asscciated with fd
- acl_delete_def_file   delete default ACL associated with file
- acl_get_fd            get ACL associated with fd
- acl_get_file               get ACL associated with file
- acl_set_fd            set ACL assciated with fd
- acl_set_file               set ACL associated with file

POSIX.6 functions to translate an ACL into different formats
- acl_copy_ext               export ACL in implementation-defined format
- acl_copy_int               import ACL in implementation-defined format
- acl_from_text              import ACL in text format
- acl_size                   size implementation-defined format
- acl_to_text           export ACL in text format



5. DCE

DCE 1.0 currently provides an example authorisation facility which 
is intended to be supplanted in DCE 1.1 by a standard DCE ACL 
library which includes backing store.

DCE 1.0 (and, it is expected, DCE 1.1) implements a generalisation 
of the POSIX.6 ACL model such that POSIX.6 concepts and POSIX.6 D12 
ACL evaluation semantics are followed, but POSIX.6  functions aren't 
supported.  

Unlike POSIX.6 (which defines ACLs for POSIX.1 files), DCE defines a 
set of ACL types for use within DCE, and enables applications to 
invent their own types (and the different associated "ACL 
Managers").  However, this means that applications must maintain the 
link between application objects and ACLs.

Like POSIX.6, DCE defines a set of ACLE types (effectively a 
superset of POSIX.6).  DCE ACLEs, again like POSIX.6, contain a type 
(like the .6 qualifier), type-specific data, and a permission set.

The APIs intended to be supported by DCE1.1 are:
- dce_acl_register_object_type              called to register ACL type

- dce_acl_is_client_authorised              decide access based on ACL 
                                                 and permissions

- dce_acl_inq_client_permissions       get initiator permissions
- dce_acl_inq_permset_for_PAC               get POSIX subset of above
- dce_acl_inq_client_pac                    get (DCE1.0) PAC

- dce_acl_obj_create                        create ACL
- dce_acl_obj_free                          free ACL

- dce_acl_obj_add_user_entry           add ACLE for user
- dce_acl_obj_add_group_entry               add ACLE for group

- dce_acl_obj_add_id_entry                  add ACLE for other id

- dce_acl_obj_add_unauth_entry              add "unauthenticated" ACLE
- dce_acl_obj_add_obj_entry                 add general ACLE
- dce_acl_obj_add_foreign_entry             add "foreign" ACLE

In order to enable the ACL manager to get the ACL associated with an 
object, each application developer must use a default "resolver" 
function, or specify its own 



6. General Portability Model

For maximum applicability, an authorisation facility and the 
associated interfaces should be able to work in a number of 
different distributed environments.

The mechanism for retrieval of the client's ADI and its 
representation may, and in practice do, differ between mechanisms 
such as:
- Kerberos
- DCE
- X.500
- Netware
- NT/Cairo
- SESAME
- TMACH
(see Ex-GSS for an overview of these mechanisms)

Furthermore, a model is needed which allows for existing distributed 
applications to use authorisation services independent of how the 
acquisition of client ADI is achieved such that application logic is 
unaffected by migration towards distribited systems.

Given that applications may implement complex access control 
mechanisms, it is important to separate out generic ADF functions 
from applications-specific ones.

The following figure identifies the main interfaces associated with 
general model for software access decision functionality:
 
+----------------------+----------------------+    +-----------------+
|                      |                      |    |                 |
| Application Service  | Application Resource |    | Application     |
| Instance             |       Access         |    | Resource        |
| Initialisation       |                      |    | Management      |
|                      |                      |    | (including      |
|                      |                      |    |  possible app-  |
|                      |                      |    |  specific ADF)  |
|                      |                      |    |                 |
+----------------------+----------------------+    +-----------------+
           |                       |                       |
           |                       |                       |
           |           2           V               4       V
           |          ==========================  =====================
           |           |                      |    |                 |
           |           | Access Decision      |    | ADF SMIB        |
           |           | Function (ADF)       |    |                 |
           |           |                      |    |                 |
           |           +----------------------+    +-----------------+
           |                       |
           |                       |
1          V           3           V
==================....==========================   
 |              |      |                      |    
 |   Secure     |      | Client ADI Retrieval |    
 | Association  |      |                      |    
 |              |      |                      |    
 +--------------+......+----------------------+    

The proposed interfaces are as follows:

1. Secure association
   The could be implicit for simple applications, or GSS-API (etc) 
   for distributed applications, or an equivalent store-and-forward
   security API for messaging applications.

2. Access decision function
   A general interface is needed, this could be of the form
   developed by the AAC WG:
   check-authorisation
    [OUT]     output,                       - boolean or application-
                                              specific response
    [IN] security context,        - reference to authentication 
                                              context (if not defaulted)
    [IN] target,                       - objectname with namespace
                                              specified in control-
                                              parameters
    [IN] operation,                    - requested permission (subject
                                              to namespace in control 
                                              parameters)
    [IN] control-parameters       - where control-parameters 
                                              indicates the name-space and
                                              form of the other arguments

3. Attribute retrieval API
   Insulates whether attributes are obtained from a PAC, local file,  
   or directory. Possibly gss_get_attributes from Ex-GSS.

4. Management API
   Interface to the ADF SMIB.

While different name-spaces can be supported, the complete 
portability of the above interfaces are dependent on a naming 
convention being agreed (perhaps based on XFN) which insulates 
applications from the naming used by specific distributed 
environments.



7. Conclusions

Its is proposed that the following follow-on activities are 
required:

(1) XDSF improvements
    
    The XDSF model needs some additional material to:
    
    *    separate out services of concern to application developers and 
         mechanism providers
    
    *    provide concrete examples for services identified, in particular 
         the operational services identifier

(2) Portability Model
    
    Definition of a complete mechanism-independent authorisation 
    facility portability model which takes the best of DCE and POSIX, 
    but doesn't preclude applicability to other environments such as 
    existing application servers, X.500 DSA implementations, and Netware 
    NDS.
    
    Section 6, above, is suggested as a starting point with the 
    next steps being:
    - refinement of specification to a set of C bindings for
      interfaces 2 and 4 above
    - agreement of external ACL format
    - agreement of attribute types and syntaxes (and a registration
      procedure for new ones)
    - implementations for stand-alone systems (using either
      password or Kerberos authentication mechanisms), and
      distributed authorisation systems (such as DCE,
      Restricted Proxies, SESAME)



-------------------------------------------------------
P V McMahon                                     23MAY94
ICL Enterprises
post:  Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: [e-mail]
  OR   [e-mail]
phone: [phone]
fax:   [phone]
-------------------------------------------------------