Network Working Group S. Hole
Internet Draft: ACAP Authid Dataset Classes A. Melnikov
ACI WorldWide/MessagingDirect
Document: draft-ietf-acap-authid-03.txt June 2002
Expires in 6 months
ACAP Authorization Identifier Dataset Classes
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
A version of this draft document is intended for submission to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This
document will expire six months after publication. Distribution of
this draft is unlimited.
Copyright Notice
Copyright (C) The Internet Society 2002. All Rights Reserved.
0. Administrivia
0.1. Open Issues
Hole, Melnikov [Page 1]
Internet Draft ACAP Authid Dataset Classes June 2002
1) The calculation for resolving to a unique list of users from a set
of group references might need some discussion.
2) There is an unconsistency between userid.memberof and the group
entry syntax. userid.memberof uses relativeURL syntax, that coin-
cides with entry-path syntax. It is desirable to use the same syn-
tax for groupid-entry-ref/userid-entry-ref. However the syntax for
"entry" attribute doesn't allow slashes, so groupid-entry-ref and
and userid-entry-ref use "groupid." and "userid." as prefixes.
Suggestions are welcome.
0.2. Changes from revision 00
1) Added a glossary of terms section at the beginning.
2) Changed the group.members attribute of a groupid entry from a mul-
tivalued attribute to a subdataset attribute. This is to address
the scaling issues of very large groups, insertion and deletion.
Each entry in the subdataset refers to a member -- either a userid
or groupid. The namespace for userid and groupid is separated by
prefixing all userid member references with the "userid." prefix
string, and all groupid member references are prefixed with a
"groupid." string.
3) Punted on the issue of recursive or circular group references. It
is up to the agent using the group information to do spanning tree
calculations and/or set reductions to arrive at a unique membership
list. This MAY include the ACAP server itself if it uses the
authid dataset classes for authorization information.
0.3. Changes from revision 01
1) Some attributes were missing text whether they are single valued or
multi valued
2) Fixed typo in ACL definition. Fixed attribute names to conform to
ACAP spec.
Hole, Melnikov [Page 2]
Internet Draft ACAP Authid Dataset Classes June 2002
3) Corrected userid.whitepage-info definition - relativeURL was used
instead of URL
4) Added text explaining that fully qualified userids/groupids must be
used in ACLs.
5) Added example
6) Added capability registration forms. Updated address and copyright
information. Some other minor editorial changes.
1. Introduction
Most distributed (client/server) applications require an authenti-
cation process between the client and the server before the server
will grant access to its managed resources. Many applications pro-
vide varying levels of access to server resources based on a combi-
nation of authentication credentials and access control rules.
The collection of information used to control access to resources
is called "authorization information".
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 under-
lying authentication mechanisms and credential formats. They can
be extended to include group memberships in dynamic calculations
for access rights to resources or in definition of one time autho-
rization certificates.
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 capabili-
ties that advertise a server's support for authorization user and
group semantics.
2. Conventions used in this document
Hole, Melnikov [Page 3]
Internet Draft ACAP Authid Dataset Classes June 2002
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in [KEYWORD].
The attribute syntax specifications use the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF].
3. Definition of Terms
Historically, different operating and network systems have used
authentication and authorization terminology interchangeably. They
often did not distinguish between authentication and authorization,
binding both into a single process. Terms like "userid", "user-
name", "login", "access" and others are used and mean somewhat dif-
ferent things in different systems.
Following is an introductory glossary of the terminology used by
this specification. The terminology is defined specifically for
Internet client/server applications, although the terminology could
be applied to any application. It reuses some historical terms,
but defines each with a specific role, scope and usage.
3.1. Authentication and authorization model
Granting access to server resources in a client/server application
is a two step process. Step 1 is called "authentication", Step 2
is "authorization". Step 1 is performed once per session and
establishes the identity of the individual that desires to access
server resources. Step 2 may be executed many times as access
rights for the authenticated client are calculated for different
resources managed by the server.
In the ACAP model, authentication information is held independently
of and bound to authorization information using the ACAP authoriza-
tion identifiers.
3.2. Glossary of Terms
authid
The "authentication identifier" used to uniquely identify the indi-
vidual connecting to a service. The syntax and semantics of
authids are specific to a particular authentication mechanism, net-
work, and/or host operating system.
Hole, Melnikov [Page 4]
Internet Draft ACAP Authid Dataset Classes June 2002
userid
The "authorization user identifier" used to identify an individual
that a service will grant access rights to for its managed
resources. The syntax and semantics of ACAP userids are applica-
tion independent.
groupid
The "authorization group identifier" used to identify a set of
individuals and/or groups that a service will grant access rights
to for its managed resources. The syntax and semantics of ACAP
groupids are application independent.
rights
The type of access that an individual is granted to a resource.
The specific rights that can be granted to a resource is applica-
tion specific.
ACL
An "access control list" is a set of rules that binds an authoriza-
tion id (userid, groupid) to a set of rights. The form and con-
tent of ACLs are application specific.
authentication
The negotiation between a client and server application that unam-
biguously establishes the identity of the client and server par-
ties.
authorization
The calculation performed by the server to grant access rights to a
resource for an authenticated client.
Hole, Melnikov [Page 5]
Internet Draft ACAP Authid Dataset Classes June 2002
4. Authorization user identifiers
An ACAP "userid" (user identifier) is an abstraction for an indi-
vidual user that accesses server resources -- an authorization
user. Typically, this is a person acting as him or herself, a per-
son 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.
4.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.
4.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 applica-
tion resources. An application supporting ACAP "USER" authoriza-
tion semantics (as defined in section 5.) binds userids to its
resource access control rules. Resource access rights are calcu-
lated by applying, in an application specific way, the access con-
trol rules that are bound to the current user's userid.
4.2.1. Mandatory userid attributes
entry
The "entry" attribute MUST be defined for a userid entry. It's
value is a userid. The "entry" attribute is used by applications to
calculate access rights to server resources. This SHOULD include
the ACAP server itself. The syntax for the "entry" attribute is
defined in [ACAP].
Hole, Melnikov [Page 6]
Internet Draft ACAP Authid Dataset Classes June 2002
userid.authid
The "userid.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.
userid.authid ::= 1*TEXT_UTF8_CHAR
;; multi-valued
4.2.2. Optional userid attributes
userid.displayname
The "userid.displayname" attribute MAY be defined for a userid
entry. It MUST be single valued. 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, e.g.
the user's full name.
userid.displayname ::= 1*TEXT_UTF8_CHAR
userid.description
The "userid.description" attribute MAY be defined for a userid
entry. It MUST be single valued. The value contains text that
provides an extended description of the user. This information can
be presented to a user to assist them in disambiguating userid
entries with similar (or identical) "userid.displayname" attribute
values.
userid.description ::= 1*TEXT_UTF8_CHAR
userid.whitepage-info
The "userid.whitepage-info" attribute MAY be defined for a userid
entry. It MAY be multivalued. The value contains one or more
URL's that reference whitepages information for the user. There
are no restrictions on the type of the URL, but it is most likely
that the URL will be either an ACAP URL pointing to an addressbook
dataset class entry or an LDAP URL pointing to a person entry.
This information can be presented to a user to assist them in dis-
ambiguating userid entries with similar (or identical) "userid.dis-
playname" attribute values.
Hole, Melnikov [Page 7]
Internet Draft ACAP Authid Dataset Classes June 2002
userid.whitepage-info ::= URL
;; as defined in [REL-URL]
;; ACAP relative URL is defined in [ACAP]
userid.memberof
The "userid.memberof" attribute MUST be defined for an entry if the
server supports the ACAP "GROUP" authorization semantics. It MAY be
multivalued. The value of the attribute is the list of groupids
that the userid is a member of. It is provided as an 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.
userid.memberof ::= relativeURL
;; as defined in [REL-URL]
;; ACAP relative URL is defined in [ACAP]
5. Authorization group identifiers
An ACAP "groupid" (group identifier) is an abstraction for a set of
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.
5.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.
5.2. Groupid entry attributes
A "groupid" entry defines an authorization group for an applica-
tion. 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.
Each "groupid" entry is a subdataset entry. Each entry in the
Hole, Melnikov [Page 8]
Internet Draft ACAP Authid Dataset Classes June 2002
subdataset is called a "member" and references either a userid or
another groupid entry.
5.2.1. Mandatory groupid attributes
entry
The "entry" attribute MUST be defined for a groupid entry. Its
value is a groupid and it is used by applications to calculate
access rights to server resources. This SHOULD include the ACAP
server itself. The syntax for the "entry" attribute is defined in
[ACAP].
subdataset
The "subdataset" attribute MUST be defined for a groupid entry.
Its value is a relative URL pointing to a dataset whose entries are
the members of the group. The syntax for the "subdataset"
attribute is defined in [ACAP].