INTERNET DRAFT                                   Expires: December, 1997
ACAP Working Group                                               S. Hole
Internet Draft: ACAP                                The Esys Corporation
Document: draft-ietf-acap-authid-00.txt                        July 1997


                 ACAP Authorization Identifier Datasets


Status of this memo

     This document is an Internet Draft.  Internet Drafts are working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups.  Note that other groups may also distribute
     working documents as Internet Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months.  Internet Drafts may be updated, replaced, or obsoleted by
     other documents at any time.  It is not appropriate to use Internet
     Drafts as reference material or to cite them other than as a
     ``working draft'' or ``work in progress``.

     To learn the current status of any Internet-Draft, please check the
     1id-abstracts.txt listing contained in the Internet-Drafts Shadow
     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
     munnari.oz.au.

     Discussion and suggestions for improvement are requested.  This
     document will expire six months after publication.  Distribution of
     this draft is unlimited.


0. Administrivia

0.1.  Changes from Last Internet Draft

0.2.  Open Issues

1)   The definitions for authentication id's and tying authids to
     userids is somewhat problematic.   Should we have specific authid
     types (Kerberos principals, usernames, etc.) expressed as
     individual attributes, or is a single multivalued attribute enough.


2)   We may want to consider a more structured namespace for the userid
     and groupid datasets.   A per-application space below the top level
     dataset could be used to do explicit per-application "account"
     management.



Hole                                                            [Page 1]


Internet Draft       ACAP Authorization Identifiers            July 1997


     As defined right now, the application is expected to retain
     "account" information in it's private space.   That is, the
     assignment of what userid has access to things on a particular
     server is private server data - perhaps held in ACAP, but perhaps
     not.


3)   What language to use for an ACAP server that has the /userid and
     /groupid datasets and (MAY, SHOULD, MUST) use that information
     itself?


4)   There is potential for a number of other optional userid and
     groupid attributes.  Examples are:
           - disabled flag
           - expiration date


1. Introduction

     Most distributed (client/server) applications require an
     authentication process between the client and the server before the
     server will grant access to its managed resources.  Many
     applications provide varying levels of access to server resources
     based on a combination of authentication credentials and access
     control rules.   The collection of information used to control
     access to resources is called "authorization information".

     The ACAP authentication identifier datasets offers a more powerful,
     secure, and user friendly representation for authorization
     information than simple authentication identifiers in distributed
     applications.  The authorization identifer datasets contain lists
     of users and groups of users that can be used by applications for
     authorization purposes.  Access control mechanisms can be
     abstracted from underlying authentication mechanisms and credential
     formats.  They can be extended to include group memberships in
     calculations for access rights to resources.

     The Application Configuration Access Protocol (ACAP) supports the
     remote storage and access of many types of structured configuration
     information.  The authorization identifier datasets specification
     describes the "userid" and "groupid" datasets which contain the
     authorization information.  It also describes ACAP server
     capabilities that advertise a server's support for authorization
     user and group semantics.


2. Conventions used in this document



Hole                                                            [Page 2]


Internet Draft       ACAP Authorization Identifiers            July 1997


     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as described in [].

     The attribute syntax specifications use the Augmented Backus-Naur
     Form (ABNF) notation as specified in [IMAIL].


3. Authorization user identifiers

     An ACAP "userid" (user identifier) is an abstraction for an
     individual user that accesses server resources -- an authorization
     user.  Typically, this a person acting as themselves, a person
     acting in a role, or an application process.  Access rights to
     server resources can be granted or denied to a userid.

     Authentication information is tied to a userid by an authentication
     mechanism specific "authid" (authentication identifier).  More than
     one authid can be associated with a single userid.

     Userids can be listed and displayed by a client without giving away
     critical information on authentication information -- specifically
     lists of authids.   Using ACAP access control lists, the authids
     tied to a userid MAY be searched by a client but SHOULD NOT be
     retrievable by a client.


3.1. ACAP userid dataset class

     Datasets whose names begin with "/userid" contain "userid" entries
     as defined in this specification.  If present, an ACAP server
     SHOULD calculate access rights for its own information resources
     using the authorization information in this dataset.


3.2. Userid entry attributes

     A "userid" entry defines an authorization user for an application.
     It is used by the application to grant or deny access to
     application resources.  An application supporting ACAP "USER"
     authorization semantics (as defined in section 5.) binds userids to
     its resource access control rules.  Resource access rights are
     calculated by applying, in an application specific way, the access
     control rules that are bound to the current user's userid.


3.2.1.  Mandatory userid attributes





Hole                                                            [Page 3]


Internet Draft       ACAP Authorization Identifiers            July 1997


entry

     The "entry" attribute MUST be defined for a userid entry.  It's
     value is used by applications to calculate access rights to server
     resources.  This SHOULD include the ACAP server itself.


user.authid

     The "user.authid" attribute MUST be defined for userid entry.  It
     MAY be multivalued.  It contains a list of authentication mechanism
     specific authentication identifiers that bind to this userid.


3.2.2.  Optional userid attributes


user.name

     The "user.name" attribute MAY be defined for a userid entry.  It
     contains a name string which is suitable for presentation by an
     ACAP client.  If present in a userid entry, clients SHOULD present
     this value to the user rather than the value of the "entry"
     attribute.  It is assumed to contain a more descriptive label for
     the user than the userid itself, eg. the user's full name.


user.description

     The "user.description" attribute MAY de defined for a userid entry.
     It MUST be single valued.   The value contains text that describes
     the user.


user.memberof

     The "user.memberof" attribute MUST be defined for an entry if the
     server supports the ACAP "GROUP" authorization semantics.  The
     value of the attribute is the list of groupids that the userid is a
     member of.  It is provided as a optimization convenience to the
     client in the presence of group authorization semantics as defined
     in section 5.  The value is readonly and MUST be calculated by the
     server.


4. Authorization group identifiers

     An ACAP "groupid" (group identifier) is an abstraction for a set of



Hole                                                            [Page 4]


Internet Draft       ACAP Authorization Identifiers            July 1997


     users that access server resources -- an authorization group.  A
     groupid entry contains a list of userids that are members of the
     group.  Access rights to server resources can be granted or denied
     to a groupid.



4.1. ACAP groupid dataset class

     Datasets whose names begin with "/groupid" are assumed to contain
     groupid entries as defined in this specification.  If present, an
     ACAP server SHOULD support group authorization semantics defined in
     section 5.


4.2. Groupid entry attributes

     A "groupid" entry defines an authorization group for an
     application.  It is used by an application to grant or deny access
     to application resources.  An application supporting ACAP "GROUP"
     authorization semantics (as defined in section 5.) binds groupids
     to its resource access control rules.  Resource access rights are
     calculated by applying, in an application specific way, the access
     control rules that are bound to the groupids that the current
     user's userid is a member of.


4.2.1.  Mandatory groupid attributes


entry The "entry" attribute MUST be defined for a groupid entry.  Its
     value is used by applications to calculate access rights to server
     resources.  This SHOULD include the ACAP server itself.


group.members.userid

     The "group.members.userid" attribute MUST be defined for a groupid
     entry.  It MAY be multivalued.  The value of the attribute is an
     unordered list of userids that are members of the authorization
     group.


group.members.groupid

     The "group.members.groupid" attribute MUST be defined for a groupid
     entry.  It MAY be multivalued.  The value of the attribute is an
     unordered list of groupids that are members of the authorization



Hole                                                            [Page 5]


Internet Draft       ACAP Authorization Identifiers            July 1997


     group.



4.2.2.  Optional groupid attributes


group.name

     The "group.name" attribute MAY be defined for a groupid entry.  It
     contains a name string which is suitable for presentation by an
     ACAP client.  If present in a groupid entry, clients SHOULD present
     this value to the user rather than the value of the "entry"
     attribute.  It is assumed to contain a more descriptive label for
     the group than the groupid itself, eg. the group's organizational
     title.


group.description

     The "group.description" attribute MAY be defined for a groupid
     entry.  It MUST be single valued.   The value contains text that
     describes the group.



5. ACAP authorization

     The ACAP authorization information can be used by any application,
     including the ACAP server itself.  The following sections describe
     the use of the authorization identifier datasets by an ACAP
     application (client or server) itself.

     Other applications are assumed to provide their own definitions for
     use of ACAP authorization information.  Specifically, they are
     expected to define how they notify clients that their access
     control mechanisms make use of ACAP authorization information
     datasets.


5.1. Userid access semantics

     If an ACAP server supports the "/userid" dataset, then it SHOULD
     use the authorization information provided by it for access control
     purposes.  After successful authentication to the ACAP server, an
     authorization userid should be selected as the "current user" for
     the ACAP server, either using the authid mapping information in the
     userid entries, or using explicit userid information supported by



Hole                                                            [Page 6]


Internet Draft       ACAP Authorization Identifiers            July 1997


     the authentication mechanism.  ACAP ACL's are based on userids
     rather than authids.  Resource access rights are calculated
     relative to the current userid.


5.1.1. ACAP "USER" capability

     If an ACAP server supports the "/userid" dataset and userid
     authorization semantics, then it MUST express the "USER" capability
     in an ACAP capability response.   The "USER" capability informs an
     ACAP client that it MUST use the "/userid" dataset contents for any
     ACL management on the server.   If a server does not express the
     "USER" capability, then the client will assume that the server uses
     authid information in ACL's.


5.2. Group access semantics

     If an ACAP server supports the "/groupid" dataset, then it SHOULD
     use the authentication information in it.  ACAP ACL's can include
     groupids in the ACL.  Resource access rights are calculated
     relative to the current userid, and all groups that the current
     userid is a member of.


5.2.1. ACAP "GROUP" capability

     If an ACAP server supports the "/groupid" dataset and userid
     authorization semantics, then it MUST express the "GROUP"
     capability in an ACAP capability response.   The "GROUP" capability
     informs an ACAP client that it MUST use the "/groupid" dataset
     contents for any ACL management on the server.   If a server does
     not express the "GROUP" capability, then the client will assume
     that the server does not support group semantics, and should not
     present group information in ACAP ACL management functions.


6. References

     [ACAP] Newman, C., Myers, J. G., "Application Configuration Access
     Protocol", Work in progress, July 1997.

         <ftp://ietf.org/internet-drafts/draft-ietf-acap-spec-04.txt>



7. Security Considerations




Hole                                                            [Page 7]


Internet Draft       ACAP Authorization Identifiers            July 1997


     This specification defines a protocol for storing, accessing and
     managing application resource authorization information.  It is
     expected that this information will be used to grant and/or deny
     access to users and groups for server based resources.

     ACAP server access controls should be set correctly on userid entry
     attributes.  Clients SHOULD be able to search for userid entries
     based on authentication identifier attributes, but SHOULD NOT be
     able to retrieve any authentication identifier information.

     This specification does not define any kind of process, mechanism
     or protocol for authentication in distributed network applications.
     Use of the data and protocol elements described in this
     specification are to be used after successful authentication
     between the client and server.

     This specification does not discuss storage of any kind of
     authentication credentials, in the form of private keys, shared
     secrets or passwords in userid entries.   The information in the
     authid dataset is intended purely for authorization and access
     control purposes.


8. Authors' Addresses

Steve Hole
The Esys Corporation
900 10040 - 104 St.
Edmonton, Alberta, T5J 0Z2, CANADA

Email: Steve.Hole@esys.ca




















Hole                                                            [Page 8]