Subject: aznAPI, GSS-API, and GAA-API

From: [email-masked]
Date: Mon, 13 Sep 1999 10:50:02 -0700

All, 

Veselin wrote: 

>> How is [GAA] related to DASCOM's authorization API (http://www.dascom.com )?
        
Tatyana replied (her reply text is quoted; my responses are
in plain text embedded among her reply text below):

        >In contrast to the GAA, AZN API includes credential management and
        >serialization interfaces.

        This is accurate.  aznAPI has as a goal independence from
        authentication mechanisms.  Therefore it provides a way to
        import authentication data structures (for example, GSS-API
        credential handles) and turn them into authorization credentials
        without requiring the caller (i.e. the programmer, perhaps you!)
        to manipulate or understand either authorization tokens or
        credential structures.

        >I think the AZN API can be layered on top of the GAA for the credential
        >management purposes, however I do not see a clear reason for calling 
AZN
        >for checking if some operation is allowed, this is supported by the 
GAA.

        In an environment in which GAA-API is already in use, the
        reason to layer aznAPI on top of it is three-fold:

        (1) To get the benefit of transparent conversion of authentication
        tokens to credentials, which, as Tatyana points out, is not 
        a goal of GAA-API.

        (2) To hide the details of GAA ACLs from programmers.  aznAPI
        credentials are opaque (i.e. all the programmer sees is a handle),
        and aznAPI supports any access control policy storage format
        you want to use - and does not pass the policy data structures
        back across the API to the application (so it's not even a 
        requirement to be able to convert aznAPI policy structures
        into a canonical format).  GAA, in contrast, requires callers
        to retrieve policy data, and passes that data back to the 
        application in a complicated data structure which must then
        be passed to the access decision logic via another call.
        If aznAPI were layered on top of GAA-API, the GAA ACL data
        structures could be made invisible to the programmer.

        (3) To use access control functions at a higher and more flexible
        level of abstraction.  The aznAPI access decision call, for
        example, takes the standard subject-object-action descriptions
        and returns a yes/no answer.  If you want to get fancy, you
        can pass in additional context information and receive additional
        decision information, but you don't have to do this.

        By contrast, the GAA-API decision function takes in a context (
        containing complicated credential information and requiring
        in some cases quite a bit of trust evaluation), an ACL, 
        and optionally a set of rights requested (which have to be 
        determined by the calling application based on the object being 
        accessed and the operation being requested).  It returns a 
        detailed answer, from which the yes/no answer may have to be derived 
        by application logic.

        The aznAPI moves most of the processing which GAA-API callers
        do down underneath the interface into the vendor's implementation.

        In environments which don't already implement GAA-API, but
        instead have some other access control engine in place,
        you would of course simply build aznAPI directly on top of
        the interfaces of that engine.

        >One of the AZN objective is "Hide authorization attribute details, such
        >as groups, roles and clearance levels from the programmers", however
        >the API has explicit calls to obtain privileges from credentials
        >(azn_get_entitlements()) classification labels (azn_get_labels()) and
        >checking
        >clearance (azn_has_clearance()).

        This is all true. aznAPI *does* hide credential details from
        programmers.  However, some programmers don't like hidden
        details, and there are some (specialized) applications where
        the details matter to the application.  For these cases,
        we've provided interfaces which allow programmers to retrieve
        credential information (especially the auditID, in case the
        application wants to create audit records itself) and
        to retrieve policy information (entitlements) in case the
        application wants to customize the environment based on
        security policy even before an access control decision gets
        made.  However, use of these calls is completely optional,
        and we think in the majority of cases the only calls used
        will be get_credentials and access_allowed (to use the old
        names...)

        >So, in implementing multi-level policy, separate calls have to be made,
        >whereas the
        >GAA API handles it transparently within just one call.

        This is NOT true in general.  aznAPI can be used with just
        the two calls (get_credentials, which translates authentication
        data such as a certificate into authorization credentials
        containing groups, roles, clearances, etc...) and access_allowed
        (which actually makes the decision) in many MLS systems.
        However in some label-based systems it's not easy - or even
        possible - for the security runtime to tell where in a labelled
        object the labels are stored, because the labels are an
        application-specific artifact (imagine a proprietary healthcare
        system with data sensitivity labels imbedded in patient records
        -- we have customers with this configuration).  In these cases,
        it's necessary for the application to extract the label from
        the data and pass it to the API.  We've provided for this case
        by *allowing* the application to extract labels and pass them to 
        the aznAPI.  I haven't studied GAA carefully enough to know what
        it does in this case.

        Finally I should say a word or two about the relationship
        between GSS-API, GAA-API, and aznAPI.  We believe that
        an environment built on GSS-API (perhaps including XGSS-API)
        and GAA-API could be provided with an aznAPI "wrapper"
        which would support all of the functionality of the underlying
        system and support a simpler programming model, by
        handling all the GSS work of establishing connections 
        and setting up security contexts, and by handling all the
        GAA work of retrieving object ACLs, "under the covers" of
        the aznAPI implementation. 

        GSS-API allows callers to establish secure associations
        without exposing the details of authentication credential
        structures.  GSS-API does not make access control decisions,
        nor does it allow callers access to authorization-relevant
        information in the credentials it establishes.

          The GSS calling sequence is:

          acquire credential
          initialize (or accept) security context
          protect (or verify) message

        XGSS-API makes authorization-relevant information in GSS-API 
        credentials available to callers, but does not make access
        control decisions.

          The XGSS calling sequence is

          (GSS) acquire credential
          (GSS) accept security context
          (GSS) verify message
          (XGSS) get authorization data

        GAA-API allows callers to make access control decisions,
        but it does not fully hide the details of authorization policy
        data or the details of authorization-relevant authentication
        data from callers.  

          The GAA calling sequence is

          get security context (includes credential)
          get object ACL
          make access decision

        aznAPI makes authorization decisions, and it hides both
        authentication data and authorization data from applications.

          The aznAPI calling sequence is

          get credentials (from authentication data, for example GSS)
          make access decision

--bob

Bob Blakley
Chief Scientist, DASCOM
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]