mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
295 lines
10 KiB
Plaintext
295 lines
10 KiB
Plaintext
|
||
|
||
INTERNET-DRAFT Rob Weltman
|
||
Intended Category: Standards Track Netscape Communications Corp.
|
||
April 2003
|
||
|
||
LDAP Proxied Authorization Control
|
||
draft-weltman-ldapv3-proxy-12.txt
|
||
|
||
|
||
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 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.
|
||
|
||
|
||
Abstract
|
||
|
||
This document defines the Lightweight Directory Access Protocol
|
||
(LDAP) Proxy Authorization Control. The Proxy Authorization Control
|
||
allows a client to request that an operation be processed under a
|
||
provided authorization identity instead of as the current
|
||
authorization identity associated with the connection.
|
||
|
||
|
||
1. Introduction
|
||
|
||
Proxy authorization allows a client to request that an operation be
|
||
processed under a provided authorization identity instead of as the
|
||
current authorization identity associated with the connection. This
|
||
document defines support for proxy authorization using the Control
|
||
mechanism [RFC 2251]. The Lightweight Directory Access Protocol
|
||
[LDAPV3] supports the use of the Simple Authentication and Security
|
||
Layer [SASL] for authentication and for supplying an authorization
|
||
identity distinct from the authentication identity, where the
|
||
authorization identity applies to the whole LDAP session. The Proxy
|
||
Authorization Control provides a mechanism for specifying an
|
||
authorization identity on a per operation basis, benefiting clients
|
||
that need to efficiently perform operations on behalf of multiple
|
||
users.
|
||
|
||
|
||
Expires October 2003 [Page 1]
|
||
|
||
PROXIED AUTHORIZATION CONTROL April 2003
|
||
|
||
|
||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
||
used in this document are to be interpreted as described in
|
||
[KEYWORDS].
|
||
|
||
|
||
2. Publishing support for the Proxy Authorization Control
|
||
|
||
Support for the Proxy Authorization Control is indicated by the
|
||
presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
|
||
the supportedControl attribute [RFC 2252] of a server's root DSE.
|
||
|
||
|
||
3. Proxy Authorization Control
|
||
|
||
A single Proxy Authorization Control may be included in any search,
|
||
compare, modify, add, delete, modify DN or extended operation request
|
||
message with the exception of any extension that causes a change in
|
||
authentication, authorization, or data confidentiality [RFC 2829],
|
||
such as Start TLS [LDAPTLS] as part of the controls field of the
|
||
LDAPMessage, as defined in [RFC 2251].
|
||
|
||
The controlType of the proxy authorization control is
|
||
"2.16.840.1.113730.3.4.18".
|
||
|
||
The criticality MUST be present and MUST be TRUE. This requirement
|
||
protects clients from submitting a request that is executed with an
|
||
unintended authorization identity.
|
||
|
||
The controlValue SHALL be present and contain either an authzId
|
||
[AUTH] representing the authorization identity for the request or
|
||
empty if an anonymous association is to be used.
|
||
|
||
The mechanism for determining proxy access rights is specific to the
|
||
server's proxy authorization policy.
|
||
|
||
If the requested authorization identity is recognized by the server,
|
||
and the client is authorized to adopt the requested authorization
|
||
identity, the request will be executed as if submitted by the proxy
|
||
authorization identity, otherwise the result code TBD is returned.
|
||
[Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
|
||
with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
|
||
|
||
|
||
4. Implementation Considerations
|
||
|
||
One possible interaction of proxy authorization and normal access
|
||
control is illustrated here for the case of search requests. During
|
||
evaluation of a search request, an entry which would have been
|
||
returned for the search if submitted by the proxy authorization
|
||
identity directly may not be returned if the server finds that the
|
||
requester does not have the right to assume the requested identity
|
||
for searching the entry, even if the entry is within the scope of a
|
||
search request under a base DN which does imply such rights. This
|
||
|
||
Expires October 2003 [Page 2]
|
||
|
||
PROXIED AUTHORIZATION CONTROL April 2003
|
||
|
||
|
||
means that fewer results, or no results, may be returned compared to
|
||
the case where the proxy authorization identity issued the request
|
||
directly. An example of such a case may be a system with fine-grained
|
||
access control, where the proxy right requester has proxy rights at
|
||
the top of a search tree, but not at or below a point or points
|
||
within the tree.
|
||
|
||
|
||
5. Security Considerations
|
||
|
||
The Proxy Authorization Control method is subject to general LDAP
|
||
security considerations [RFC 2251] [AUTH] [LDAPTLS]. The control may
|
||
be passed over a secure as well as over an insecure channel.
|
||
|
||
The control allows for an additional authorization identity to be
|
||
passed. In some deployments, these identities may contain
|
||
confidential information which require privacy protection.
|
||
|
||
Note that the server is responsible for determining if a proxy
|
||
authorization request is to be honored. "Anonymous" users SHOULD NOT
|
||
be allowed to assume the identity of others.
|
||
|
||
|
||
6. IANA Considerations
|
||
|
||
The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
|
||
Authorization Control. It is to be registered as an LDAP Protocol
|
||
Mechanism [RFC 3383].
|
||
|
||
A result code for the case where the server does not execute a
|
||
request using the proxy authorization identity is to be assigned by
|
||
the IANA.
|
||
|
||
|
||
7. Copyright
|
||
|
||
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 implementation 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
|
||
|
||
Expires October 2003 [Page 3]
|
||
|
||
PROXIED AUTHORIZATION CONTROL April 2003
|
||
|
||
|
||
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
|
||
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.
|
||
|
||
|
||
8. Normative References
|
||
|
||
|
||
[KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
|
||
Requirement Levels", draft-bradner-key-words-03.txt, January,
|
||
1997.
|
||
|
||
[LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
||
Protocol (v3): Technical Specification", RFC 3377, September
|
||
2002.
|
||
|
||
[SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
|
||
RFC 2222, October 1997
|
||
|
||
[AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
|
||
Methods for LDAP", RFC 2829, May 2000
|
||
|
||
[LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
|
||
Access Protocol (v3): Extension for Transport Layer Security",
|
||
RFC 2830, May 2000
|
||
|
||
[RFC 2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
|
||
Protocol (v3)", RFC 2251, December 1997.
|
||
|
||
[RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
|
||
Directory Access Protocol (v3): Attribute Syntax Definitions",
|
||
RFC 2252, December 1997
|
||
|
||
[RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
|
||
"Authentication Methods for LDAP", RFC 2829, May 2000
|
||
|
||
[RFC 3383] K. Zeilenga, "Internet Assigned Numbers Authority (IANA)
|
||
Considerations for the Lightweight Directory Access Protocol
|
||
(LDAP)", RFC 3383, September 2002
|
||
|
||
9. Author's Address
|
||
|
||
Rob Weltman
|
||
Netscape Communications Corp.
|
||
360 W. Caribbean Drive
|
||
Sunnyvale, CA 94089
|
||
USA
|
||
|
||
|
||
Expires October 2003 [Page 4]
|
||
|
||
PROXIED AUTHORIZATION CONTROL April 2003
|
||
|
||
|
||
+1 650 937-3194
|
||
rweltman@netscape.com
|
||
|
||
|
||
10. Acknowledgements
|
||
|
||
Mark Smith of Netscape Communications Corp., Mark Wahl of Sun
|
||
Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim
|
||
Sermersheim of Novell, and Steven Legg of Adacel have contributed
|
||
with reviews of this document.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires October 2003 [Page 5]
|
||
|