home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_a_c
/
draft-ietf-acap-authid-00.txt
< prev
next >
Wrap
Text File
|
1997-07-24
|
16KB
|
477 lines
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]