[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
new application defined permissions draft
Please published the attached new draft. I have written this as a
companion document to the ACL Model draft. Comments welcome.
Bruce Greenblatt
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
LDAPEXT Working Group B. Greenblatt
Internet Draft Directory Tools and
Application
Services, Inc.
Document: <draft-greenblatt-ldap-perms-00.txt> April 2001
Category: Standards Track
Application Defined Permissions for LDAP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
In the current ACL Model draft [2], the kinds of permissions that an
LDAP server understands are limited to those defined in clause
4.1.1. Certain LDAP integrated applications need to store their own
Application Defined Permissions (ADP) as well. For example,
consider an application that allows users to perform several
different actions on various types of objects. Let's call these
objects foo objects, and the actions foo-1 through foo-n. None of
these correspond to the add, delete, export, etc. permissions
defined in clause 4.1.1. The application should be able to have a
ACI assigned to an entry that represents a foo object that grants
permissions to perform some foo-i actions to some list of subject
entries (i.e. users, groups, organizationalUnits, domainContexts,
etc.).
These permissions can?t be granted with the mechanisms currently
defined in the ACL Model draft. This would require a new permission
level, but it is not appropriate to shoe-horn this in to the BNF of
4.1.1 or the ASN.1 of 4.1.2. This draft will define new LDAP Schema
information for holding the application defined permissions, and
Greenblatt Standards Track ? Expires October 2001 1
Application Defined Permissions for LDAP April 2001
show how the mechanism of the ACL Model can be used with these new
schema elements.
In addition to granting rights, the applications also need to be
able to verify that a subject entry has the appropriate rights to
perform an operation against a specified object. This should work
as defined in the existing model. The effective rights control or
extended operation will work for this. The application also would
like to be able to find all of the entries in a specified scope to
which a specified user has permission to perform action foo.
This draft provides new definitions which build upon those in the
ACL Model draft that allow for application defined permissions in
addition to the system defined permissions of the ACL Model. This
draft should only be read after reading [2], as it builds on the
definitions and concepts defined there.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [3].
3. Schema for Application Defined Permissions
Servers that support ADPs MUST advertise their support by placing
the following object identifier in the
?supportedAccessControlSchemes? attribute of the root DSE:
1.3.6.1.4.1.5515.3.1
If an LDAP Server supports ADPs, the above OID MUST be specified as
a value in the accessControlSchemes attribute of the ldapACISubEntry
entry in naming contexts as appropriate.
1.3.6.1.4.1 has been assigned as IANA-registered Private
Enterprises, and IANA has assigned 5515 to Directory Tools and
Application Services, Inc. (DTASI).
1.3.6.1.4.1.5515.3 is the root OID for specified attribute values.
3.1 The Application Defined Access Control Information Attributes
The application defined access control information attributes,
applicationDefinedEntryACI and applicationDefinedSubtreeACI are
defined as:
( 1.3.6.1.4.1.5515.2.9 NAME 'applicationDefinedEntryACI' SUP
'entryACI' )
( 1.3.6.1.4.1.5515.2.10 NAME 'applicationDefinedSubtreeACI' SUP
'subtreeACI' )
Greenblatt Standards Track 2
Application Defined Permissions for LDAP April 2001
3.1.1 The BNF
Here's the BNF for permissions to include application defined
permissions. Values of this syntax use BNF encoding conventions
described in [4]. This is a slightly modified version of the BNF
defined in [2].
applicationDefinedEntryACI = rights "#" attr "#" subject
applicationDefinedSubtreeACI = rights "#" attr "#" subject
rights = (("grant:" / "deny:") permissions) /
("grant:" permissions ";deny:" permissions)
permissions = ([permission ("," permission)*])
permission = oidstring ; application defined permission
oidstring = digit ("." digit)*
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
; attr and subject are defined in [2]
3.1.2 The ASN.1 Binary Format
Here's the modified ASN.1 for permissions to include application
defined permissions. Thie following data type is used to represent
this syntax when transferred in binary form. This is a slightly
modified version of the ASN.1 defined in [2].
ApplicationDefinedEntryACI ::= SEQUENCE {
rights SEQUENCE OF CHOICE {
grant [0] ApplicationDefinedPermissions,
deny [1] ApplicationDefinedPermissions},
attr CHOICE {
all [0] NULL,
entry [1] NULL,
attributes [2] SEQUENCE OF Attribute },
subject SEQUENCE {
authnLevel CHOICE {
any [0] NULL,
simple [1] NULL,
sasl [2] CHOICE {
any [0] NULL,
mechanism [1] LDAPString -- from [LDAPv3]
}
none [3] NULL,
anonymous [4] NULL
},
Greenblatt Standards Track 3
Application Defined Permissions for LDAP April 2001
subjectName CHOICE {
dn [0] DN,
user [1] UTF8String
role [1] DN,
group [2] DN,
subtree [3] DN,
ipAddress [4] IPAddress,
public [6] NULL,
this [7] NULL }, } -- may be expanded
per [AuthMeth]
ApplicationDefinedSubtreeACI ::= SEQUENCE {
rights SEQUENCE OF CHOICE {
grant [0] ApplicationDefinedPermissions,
deny [1] ApplicationDefinedPermissions },
attr CHOICE {
all [0] NULL,
entry [1] NULL,
attributes [2] SEQUENCE OF Attribute },
subject SEQUENCE {
authnLevel CHOICE {
any [0] NULL,
simple [1] NULL,
sasl [2] CHOICE {
any [0] NULL,
mechanism [1] LDAPString -- from [LDAPv3]
}
none [3] NULL,
anonymous [4] NULL
},
subjectName CHOICE {
dn [0] DN,
user [1] UTF8String
role [1] DN,
group [2] DN,
subtree [3] DN,
ipAddress [4] IPAddress,
public [6] NULL,
this [7] NULL }, }
ApplicationDefinedPermission ::= OID
ApplicationDefinedPermissions ::= SEQUENCE OF
ApplicationDefinedPermission
4. Notes on Application Defined Permissions
In order to define an ADP, the application developer needs to
register an OID with some registration authority (such as IANA).
Once the application developer has obtained the OID, it can be used
as the root for defining the ADPs needed by the LDAP integrated
Greenblatt Standards Track 4
Application Defined Permissions for LDAP April 2001
application. Servers that advertise their support of the ADP
through the use 1.3.6.1.4.1.5515.3.1 the OID in the
?supportedAccesControlSchemes? MUST support any OID in values of the
the ACI information attributes: applicationDefinedEntryACI and
applicationDefinedSubtreeACI.
5. Example of an Application Defined Permissions
Application defined permissions are not intended to restrict the
ability of any subject to perform LDAP operations against any LDAP
entry. Application defined permissions are defined to allow LDAP
applications to store their access control information within LDAP
entries. For example, an electronic commerce application may make
use of LDAP to store access control information about which
customers have the ability to purchase various items that the
electronic commerce application provides. This application can
create an OID to represent the "purchase" permission. Then the
application can create entries in the DIT representing the inventory
items that are under access control. Finally, the application can
assign rights to purchase these items, by creating ACI attributes to
the inventory item entries, using other DIT entries as the subject
of the ACI attribute.
Once the DIT has been set up, the GetEffectiveRights operation and
controls can be used to determine which users have rights to
purchase various inventory items.
Example #1
dn: o=XYZ, c=US
applicationDefinedSubtreACI:
grant:5.4.3.2.1#[entry]#group:cn=G1,ou=ABC,o=XYZ,c=US
Assume that the OID 5.4.3.2.1 (which is not a legal OID), defines
the "purchase" permission. This ACI means that for the entire
subtree rooted at "o = XYZ, c=us", all members of the named group
have the permission to purchase all entries in the subtree.
Example #2
dn: cn=partNumber1,ou=parts,o=XYZ, c=US
applicationDefinedentryACI: grant:5.4.3.2.1#[entry]#authzID-
dn:cn=bgreenblatt,dc=dtasi,dc=com
Assume again the OID 5.4.3.2.1, defines the "purchase" permission.
This ACI means that the entry defined by the distinguished name
?cn=bgreenblatt,dc=dtasi,dc=com? has the permission to purchase the
item denoted by the entry ?cn=partNumber1,ou=parts,o=XYZ, c=US?.
6. Security Considerations
This document proposes protocol elements for transmission of
security policy information. Security considerations are discussed
Greenblatt Standards Track 5
Application Defined Permissions for LDAP April 2001
throughout this draft. Because subject security attribute
information is used to evaluate decision requests by applications,
it is security-sensitive information and must be protected against
unauthorized modification whenever it is stored or transmitted.
There is no interaction of application defined access controls with
any directory functions (other than the ones defined in this [2]).
7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Stokes, E., et. al., ?Access Control Model for LDAPv3?, Internet
Draft (work in Progress), March 2001.
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
4 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
8. Author's Address
Bruce Greenblatt
Directory Tools and Application Services, Inc.
6841 Heaton Moor Drive
San Jose, CA 95119
Email: bgreenblatt@directory-applications.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
Greenblatt Standards Track 6
Application Defined Permissions for LDAP April 2001
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Greenblatt Standards Track 7