external/bsd/openldap/dist/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt

   1
   2
   3
   4
   5
   6
   7
   8 Internet-Draft                                     E. Stokes
   9 LDAP Extensions WG                                B. Blakley
  10 Intended Category: Standards Track            Tivoli Systems
  11 Expires: 14 January 2001                        D. Rinkevich
  12                                                          IBM
  13                                                     R. Byrne
  14                                             Sun Microsystems
  15                                                 14 July 2000
  16
  17               Access Control Model for LDAPv3
  18            <draft-ietf-ldapext-acl-model-06.txt>
  19
  20 STATUS OF THIS MEMO
  21
  22 This document is an Internet-Draft and is in full
  23 conformance with all provisions of Section 10 of RFC2026.
  24
  25 Internet-Drafts are working documents of the Internet
  26 Engineering Task Force (IETF), its areas, and its working
  27 groups. Note that other groups may also distribute working
  28 documents as Internet-Drafts. Internet-Drafts are draft
  29 documents valid for a maximum of six months and may be
  30 updated, replaced, or obsoleted by other documents at any
  31 time. It is inappropriate to use Internet-Drafts as
  32 reference material or to cite them other than as "work in
  33 progress."
  34
  35 The list of current Internet-Drafts can be accessed at
  36 http://www.ietf.org/ietf/1id-abstracts.txt
  37
  38 The list of Internet-Draft Shadow Directories can be
  39 accessed at http://www.ietf.org/shadow.html.
  40
  41 Comments and suggestions on this document are encouraged.
  42 Comments on this document should be sent to the  LDAPEXT
  43 working group discussion list:
  44
  45           ietf-ldapext@netscape.com
  46
  47 COPYRIGHT NOTICE
  48
  49 Copyright (C) The Internet Society (2000).  All Rights
  50 Reserved.
  51
  52 ABSTRACT
  53
  54 This document describes the access control model for the
  55 Lightweight Directory Application Protocol V3 (LDAPv3)
  56 directory service. It includes a description of the model,
  57 the LDAP controls, and the extended operations to the LDAP
  58 protocol.  The current LDAP APIs are sufficient for most
  59
  60
  61
  62 Stokes, et al      Expires 14 January 2001          [Page 1]
  63 \f
  64
  65
  66
  67
  68 Internet-Draft      Access Control Model        14 July 2000
  69
  70
  71
  72 access control operations.  An API (in a separate document)
  73 is needed for the extended operation getEffectiveAccess.  A
  74 separate requirements document for access control exists
  75 [REQTS].  The access control model used the requirements
  76 documents as a guideline for the development of this
  77 specification and are reflected in this specification to the
  78 extent that the working group could agree on an access
  79 control model.
  80
  81
  82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
  83 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  and
  84 "MAY" used in this document are to be interpreted as
  85 described in [Bradner97].
  86
  87
  88
  89 1.  Introduction
  90
  91 The ability to securely access (replicate and distribute)
  92 directory information throughout the network is necessary
  93 for successful deployment.  LDAP's acceptance as an access
  94 protocol for directory information is driving the need to
  95 provide an access control model definition for LDAP
  96 directory content among servers within an enterprise and the
  97 Internet.  Currently LDAP does not define an access control
  98 model, but one is needed to ensure consistent secure access,
  99 replication, and management across heterogeneous LDAP
 100 implementations. The major objective is to provide a simple,
 101 usable, and implementable, but secure and efficient access
 102 control model for LDAP while also providing the appropriate
 103 flexibility to meet the needs of both the Internet and
 104 enterprise environments and policies.  This document defines
 105 the model and the protocol extensions (controls and extended
 106 operations).
 107
 108 This draft does not (and cannot) fully specify the behavior
 109 of the Access Control Model in a distributed environment
 110 (e.g. propagating access control information across servers
 111 and ACI administration) because there is no LDAP standard
 112 defining how to distribute directory data between LDAP
 113 servers.  The behavior of the Access Control Model in
 114 distributed environments is beyond the scope of this draft.
 115
 116
 117
 118 2.  The LDAPv3 Access Control Model
 119
 120 Access Control mechanisms evaluate requests for access to
 121 protected resources and make decisions about whether those
 122 requests should be granted or denied.  In order to make a
 123
 124
 125
 126 Stokes, et al      Expires 14 January 2001          [Page 2]
 127 \f
 128
 129
 130
 131
 132 Internet-Draft      Access Control Model        14 July 2000
 133
 134
 135
 136 grant/deny decision about a request for access to a
 137 protected resource, an access control mechanism needs to
 138 evaluate policy data.  This policy data describes security-
 139 relevant characteristics of the requesting subject and the
 140 rules which govern the use of the target object.
 141
 142 No mechanism is defined in this document for storage of
 143 access control information at the server beyond indicating
 144 that the attribute holding access control information is an
 145 operational attribute.
 146
 147 The access control mechanisms specified in this document are
 148 neutral with respect to policy inheritance mechanisms,
 149 explicit vs. implicit denial, and group nesting.
 150
 151 The access control model defines
 152
 153    - What flows on the wire for interoperability
 154
 155      The existing LDAP protocol flows for ldap operations
 156      are used to manipulate access control information.  A
 157      set of permissions and their semantics with respect to
 158      ldap operations is defined.  The permissions parallel
 159      the types of ldap operations defined.  What is
 160      transmitted is exactly what is read back.  Encoding of
 161      access control information on the wire is per the
 162      LDAPv3 specifications.
 163
 164      There is an additional LDAP control and extended
 165      protocol operation defined, getEffectiveRights.  LDAP
 166      clients use the control and extended operation to
 167      manage and administer access control policy enforced by
 168      LDAP servers.
 169
 170      Servers may store access control information in any way
 171      they choose. In particular, servers may use the access
 172      control mechanisms of their datastores to store and
 173      enforce LDAP access control, or they may implement
 174      access control managers external to their datastores.
 175      Datastores and external access control managers MAY
 176      implement any access control rule syntax and semantics
 177      they choose, but the semantics MUST be compatible with
 178      those defined in the section titled "Operational
 179      Semantics of Access Control Operations".
 180
 181    - Attributes and classes for application portability of
 182      access control information
 183
 184      An access control information attribute (ldapACI) for
 185      application portability:  This attribute is used as
 186      input to the LDAP APIs so access control information
 187
 188
 189
 190 Stokes, et al      Expires 14 January 2001          [Page 3]
 191 \f
 192
 193
 194
 195
 196 Internet-Draft      Access Control Model        14 July 2000
 197
 198
 199
 200      can be addressed uniformly independent of how that
 201      information is addressed and stored at the server.
 202      This same attribute appears in LDIF output for
 203      interchange of access control information.
 204
 205      An access control information subentry class
 206      (ldapACISubEntry) and a set of attributes
 207      (supportedAccessControlSchemes which is used in the
 208      rootDSE and accessControlSchemes which is used in the
 209      subentry ldapACISubEntry) to identity the access
 210      control mechanisms supported by a server and in a given
 211      part of the namespace, respectively.
 212
 213    - An attribute in the rootDSE, discloseOnError, to
 214      control whether it is permissible for the server to
 215      return the name of an entry or attribute in an error
 216      (or empty set) operation result.  This closes a hole on
 217      the ability to discover information you are not
 218      authorized to discover.
 219
 220    - A mechanism to control access to access control
 221      information:  The access control information attribute,
 222      ldapACI, is used to control access to access control
 223      information (controls access to itself).  How to get an
 224      initial ldapACI in the directory is server specific and
 225      beyond the scope of this model.
 226
 227 Servers can support multiple access control mechanisms, but
 228 MUST be capable of supporting the LDAP Mechanism in the DIT
 229 scoped by the rootDSE (entire server's DIT) for that server
 230 and SHOULD be capable of supporting the LDAP mechanism in an
 231 arbitrary part (subtree) of the DIT.
 232
 233 The accessControlSchemes attribute in the ldapACISubEntry
 234 indicates which access control mechanism is in effect for
 235 the scope of that ldapACISubEntry.  The
 236 supportedAccessControlSchemes attribute in the rootDSE
 237 indicates which acess control mechanisms are supported by
 238 the server; those mechanisms are in effect in that server's
 239 DIT unless overridden by a mechanism defined in a
 240 ldapACISubEntry elsewhere in that DIT.
 241
 242 Changing the value(s) of either the
 243 supportedAccessControlSchemes or accessControlSchemes
 244 attributes changes the mechanism(s) in effect for the scope
 245 of those attributes (where scope is either that of the
 246 rootDSE or ldapACISubEntry).
 247
 248 Through the use of the mechanism rootDSE attribute and
 249 ldapACI subentry, it is possible to run multiple mechanisms
 250 in either the same subtree or separate subtrees.  If two
 251
 252
 253
 254 Stokes, et al      Expires 14 January 2001          [Page 4]
 255 \f
 256
 257
 258
 259
 260 Internet-Draft      Access Control Model        14 July 2000
 261
 262
 263
 264 mechanisms are run in the same subtree, it is desirable that
 265 the result be the same independent of mechanism, but
 266 definition and discussion of this is beyond the scope of
 267 this model.
 268
 269
 270
 271 3.  Access Control Mechanism Attributes
 272
 273 Two attributes are defined to identify which access control
 274 mechanisms are supported by a given server and by a given
 275 subtree:  supportedAccessControlSchemes and
 276 accessControlSchemes.  (We chose these names based on the
 277 X.500 attribute, AccessControlScheme which is single-valued
 278 and defined in X.501).
 279
 280
 281 3.1  Root DSE Attribute for Access Control Mechanism
 282
 283 The server advertises which access control mechanisms it
 284 supports by inclusion of the 'supportedAccessControlSchemes'
 285 attribute in the root DSE.  This attribute is a list of
 286 OIDs, each of which identify an access control mechanism
 287 supported by the server.  By default, these are also the
 288 mechanisms in effect in subtrees beneath the root in that
 289 server unless overridden by a ldapACISubEntry (see section
 290 "Subentry Class Access Control Mechanism").
 291
 292  (<OID to be assigned>
 293     NAME      'supportedAccessControlSchemes'
 294     DESC      list of access control mechanisms supported
 295                 by this directory server
 296     SYNTAX    LDAPOID
 297     USAGE     dSAOperation
 298  )
 299
 300 The access control mechanism defined is:
 301      LDAPv3     <OID to be assigned>
 302
 303 Other vendor access control mechanisms MAY be defined (by
 304 OID) and are the responsibility of those vendors to provide
 305 the definition and OID.
 306
 307
 308 3.2  Root DSE Attribute for Control of Disclosing Errors
 309
 310 The server specifies whether it is permissible for the name
 311 of an entry or attribute to be disclosed in an error (or
 312 empty) operation result.  This rootDSE attribute is
 313 discloseOnError.  The default for discloseOnError is false
 314 (0) or not to disclose on error.  The lack of this attribute
 315
 316
 317
 318 Stokes, et al      Expires 14 January 2001          [Page 5]
 319 \f
 320
 321
 322
 323
 324 Internet-Draft      Access Control Model        14 July 2000
 325
 326
 327
 328 in the rootDSE is interpreted as the default.
 329
 330  (<OID to be assigned>
 331     NAME      'discloseOnError'
 332     DESC      specify whether to return the name of an
 333                 entry or attribute in an error (or
 334                 empty) operation result; 0=do not
 335                 disclose (default); 1=disclose
 336     SYNTAX    LDAPString
 337     USAGE     dSAOperation
 338
 339
 340 3.3  Subentry Class Access Control Mechanism
 341
 342 A given naming context MUST provide information about which
 343 access control mechanisms are in effect for that portion of
 344 the namespace.  This information is contained in a subentry
 345 (ldapACISubEntry class), derived from [SUBENTRY].
 346 ldapACISubEntry MAY be used to define the scope of an access
 347 control mechanism.  The value(s) held in the rootDSE
 348 attribute, supportedAccessControlSchemes, are the mechanisms
 349 in effect in subtrees beneath the root in that server unless
 350 overridden in a ldapACISubEntry further down the tree held
 351 by that server.  The scope of that ldapACISubEntry is to the
 352 end of the subtree held by that server or until another
 353 ldapACISubEntry is encountered in that subtree held by that
 354 server.  The ldapACISubEntry class is defined as:
 355
 356
 357  ( <OID to be assigned>
 358      NAME   'ldapACISubEntry'
 359      DESC   'LDAP ACI Subentry class'
 360      SUP    ldapSubEntry STRUCTURAL
 361      MUST   ( accessControlSchemes )
 362  )
 363
 364 The accessControlSchemes attribute MUST be in each ldap
 365 access control subentry entry associated with a naming
 366 context whose access control mechanism is different from
 367 adjacent naming contexts supported by that directory server.
 368 accessControlSchemes lists the values (list of OIDs) that
 369 define the access control mechanisms in effect for the scope
 370 of that ldap access control subentry.  Although, in general,
 371 this attribute will define only a single mechanism (single
 372 value), more than one mechanism MAY be in effect for the
 373 scope of that subentry.
 374
 375  (<OID to be assigned>
 376     NAME      'accessControlSchemes'
 377     DESC      list of access control mechanisms supported
 378                 in this subtree
 379
 380
 381
 382 Stokes, et al      Expires 14 January 2001          [Page 6]
 383 \f
 384
 385
 386
 387
 388 Internet-Draft      Access Control Model        14 July 2000
 389
 390
 391
 392     SYNTAX    LDAPOID
 393     USAGE     dSAOperation
 394  )
 395
 396
 397
 398 4.  The Access Control Information Attribute (ldapACI)
 399
 400 The access control information attribute, ldapACI, is
 401 defined as:
 402
 403  (<OID to be assigned>
 404    NAME      'ldapACI'
 405    DESC      'ldap access control information'
 406    EQUALITY  caseIgnoreMatch
 407    SYNTAX    directoryString
 408    USAGE     directoryOperation
 409  )
 410
 411 The intent of the attribute definition is to design a common
 412 interchange format.  Any given LDAP server should be able to
 413 translate the below defined attribute into meaningful
 414 operation requests. Each server should be able to understand
 415 the attribute; there should not be any ambiguity into what
 416 any part of the syntax means.
 417
 418 While the end goal is to have a common behavior model
 419 between different LDAP server implementations, the attribute
 420 definition alone will not ensure identical ACL processing
 421 behavior between servers.  The semantics of how a server
 422 interprets the ACI syntax are defined in the "Operational
 423 Semantics of Access Control" section of this document.
 424 Additionally, while the server must recognize and act on the
 425 attribute when received over the wire, there are no
 426 requirements for the server to physically store this
 427 attribute.
 428
 429 The attribute definition maintains an assumption that the
 430 receiving server supports inheritance within the security
 431 model. If the server does not support inheritance, the
 432 receiving server must expand any inherited information based
 433 on the scope flag.  If the server does not support partial
 434 inheritance and both the entry and subtree scope are used,
 435 then entry is the prevailing scope.  (It is possible for two
 436 values in the ldapACI attribute to have different scopes
 437 given the syntax of ldapACI; one might contain 'entry' and
 438 another might contain 'subtree'.  This implies that some
 439 ldapACI values inherit down the DIT and othersdo not - hence
 440 partial inheritance of the ldapACI attribute.)
 441
 442 The attribute is defined so access control information (ACI)
 443
 444
 445
 446 Stokes, et al      Expires 14 January 2001          [Page 7]
 447 \f
 448
 449
 450
 451
 452 Internet-Draft      Access Control Model        14 July 2000
 453
 454
 455
 456 can be addressed in a server independent of server
 457 implementation.  This attribute is used in typical LDAP APIs
 458 and in LDIF output of ACI. This attribute may be queried or
 459 set on all directory objects.  The BNF and definitions are
 460 given below.
 461
 462
 463 4.1  The BNF
 464
 465
 466 4.1.1  ACI String Representation
 467
 468  Values of this syntax are encoded according to the
 469  following BNF which follows the BNF encoding
 470  conventions described in [ABNF]:
 471
 472  ldapACI = scope "#" rights "#" attr "#" subject
 473
 474  scope = "entry" / "subtree"
 475
 476  rights = (("grant:" / "deny:") permissions) /
 477           ("grant:" permissions ";deny:" permissions)
 478
 479  permissions = [permission *("," permission)]
 480
 481  permission = "a" / ; add
 482               "d" / ; delete
 483               "e" / ; export
 484               "i" / ; import
 485               "n" / ; renameDN
 486               "b" / ; browseDN
 487               "t" / ; returnDN
 488               "r" / ; read
 489               "s" / ; search
 490               "w" / ; write (mod-add)
 491               "o" / ; obliterate (mod-del)
 492               "c" / ; compare
 493               "m" / ; make
 494
 495  attr = "[all]" / "[entry]" / (attribute *("," attribute))
 496
 497  attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38)
 498              ;     from [ATTR]
 499
 500  subject = ["authnLevel:" authnLevel ":"]
 501              (("authzID-" authzID) /
 502              ("role:" dn) /
 503              ("group:" dn) /
 504              ("subtree:" dn) /
 505              ("ipAddress:" ipAddress) /
 506              "public:" /
 507
 508
 509
 510 Stokes, et al      Expires 14 January 2001          [Page 8]
 511 \f
 512
 513
 514
 515
 516 Internet-Draft      Access Control Model        14 July 2000
 517
 518
 519
 520              "this:")
 521
 522  authnLevel = "any" /
 523               "simple" /
 524               sasl
 525
 526  sasl = "sasl:"
 527         ("any" /
 528         mechanism)
 529
 530  mechanism = ; sasl mechanism from 4.2 of [LDAPv3]
 531
 532  authzID = ; authzID from [AuthMeth] repeated below
 533            ;    for convenience
 534
 535  authzId = dnAuthzId / uAuthzId
 536
 537  ; distinguished-name-based authz id.
 538  dnAuthzId  = "dn:" dn
 539
 540  dn = utf8string ; with syntax defined in [UTF]
 541
 542  ; unspecified userid, UTF-8 encoded.
 543  uAuthzId   = "u:" userid
 544  userid     = utf8string ; syntax unspecified
 545
 546  ipAddress = printableString
 547                ; dotted decimal form (e.g. 10.0.0.6)
 548                ; or use wildcards such as 12.3.45.* to
 549                ;    specify a specific subnetwork
 550                ; or 123.45.6.*+255.255.255.115 to
 551                ;    specify a subnetmask
 552                ; or use a wildcard domain name such as
 553                ;    *.airius.com to specify a specific
 554                ;    DNS domain
 555
 556  printableString ; printableString syntax from [ATTR]
 557
 558
 559 Note that the colon following the "public" and "this"
 560 subject options exist only to simplify string parsing.
 561
 562 Note also that per [AuthMeth], authzID may be expanded in
 563 the future.
 564
 565 See section titled 'ACI Examples' for examples of the string
 566 representation.
 567
 568
 569
 570
 571
 572
 573
 574 Stokes, et al      Expires 14 January 2001          [Page 9]
 575 \f
 576
 577
 578
 579
 580 Internet-Draft      Access Control Model        14 July 2000
 581
 582
 583
 584 4.1.2  ACI Binary Representation
 585
 586  The following ASN.1 data type is used to represent this
 587  syntax when transferred in binary form:
 588
 589  ldapACI ::= SEQUENCE {
 590       scope      ENUMERATED {
 591             entry       (0),
 592             subtree     (1) },
 593       rights     SEQUENCE OF CHOICE {
 594             grant       [0] Permissions,
 595             deny        [1] Permissions },
 596       attr       CHOICE {
 597             all         [0] NULL,
 598             entry       [1] NULL,
 599             attributes  [2] SEQUENCE OF Attribute },
 600       subject    SEQUENCE {
 601          authnLevel   CHOICE {
 602             any      [0] NULL,
 603             simple   [1] NULL,
 604             sasl     [2] CHOICE {
 605                any       [0] NULL,
 606                mechanism [1] LDAPString -- from [LDAPv3]
 607             }
 608          },
 609       subject    CHOICE {
 610             dn          [0] DN,
 611             user              [1] utf8String
 612             role        [1] DN,
 613             group       [2] DN,
 614             subtree     [3] DN,
 615             ipAddress   [4] IPAddress,
 616             public      [6] NULL,
 617             this        [7] NULL }, } -- may be expanded
 618                                           per [AuthMeth]
 619
 620    Permissions ::= SEQUENCE OF ENUMERATED {
 621       add        (0),
 622       delete     (1),
 623       export     (2),
 624       import     (3),
 625       renameDN   (4),
 626       browseDN   (5),
 627       returnDN   (6),
 628       read       (7),
 629       search     (8),
 630       write      (9),
 631       obliterate (10),
 632       compare    (11),
 633       make       (12) }
 634
 635
 636
 637
 638 Stokes, et al      Expires 14 January 2001         [Page 10]
 639 \f
 640
 641
 642
 643
 644 Internet-Draft      Access Control Model        14 July 2000
 645
 646
 647
 648    Attribute ::= AttributeType -- from [LDAPv3]
 649
 650    IPAddress ::= PrintableString -- (e.g. 10.0.0.6)
 651
 652
 653
 654 4.2  The Components of ldapACI Attribute
 655
 656 This section defines components that comprise the access
 657 control information attribute, ldapACI.
 658
 659
 660 4.2.1  Scope
 661
 662 Two scopes for access control information are defined:
 663
 664    - entry - the access control information in the ldapACI
 665      attribute applies only to the entry in which it is
 666      contained
 667
 668    - subtree - the access control information in the ldapACI
 669      attribute applies to each entry down the subtree unless
 670      it is overridden by an entry-specific ldapACI whose
 671      values are more specific.
 672
 673 Use of prescriptive ACIs and scoping via use of a
 674 ldapACISubEntry is outside the scope of this document.
 675
 676
 677 4.2.2  Access Rights and Permissions
 678
 679 Access rights can apply to an entire object or to attributes
 680 of the object. Access can be granted or denied.  Either or
 681 both of the actions "grant" | "deny"  may be used when
 682 creating or updating ldapACI.
 683
 684 Each of the LDAP access permissions are discrete. One
 685 permission does not imply another permission.  The
 686 permissions which apply to attributes and the entry parallel
 687 the type of ldap operations that can be performed.
 688
 689 Permissions which apply to attributes:
 690
 691    r   Read        Read attribute values
 692    w   Write       Modify-add values
 693    o   Obliterate  Modify-delete values
 694    s   Search      Search entries with specified attributes
 695    c   Compare     Compare attributes
 696    m   Make        Make attributes on a new entry below
 697                      this entry
 698
 699
 700
 701
 702 Stokes, et al      Expires 14 January 2001         [Page 11]
 703 \f
 704
 705
 706
 707
 708 Internet-Draft      Access Control Model        14 July 2000
 709
 710
 711
 712   1.  r  Read
 713
 714       If granted, permits attributes and values to be
 715       returned in a read or search operation.
 716
 717   2.  w  Write
 718
 719       If granted, permits attributes and values to be added
 720       in a modify operation.
 721
 722   3.  o  Obliterate
 723
 724       If granted, permits attributes and values to be
 725       deleted in a modify operation.
 726
 727   4.  s  Search
 728
 729       If granted, permits attributes and values to be
 730       included in a search operation.
 731
 732   5.  c  Compare
 733
 734       If granted, permites attributes and value to be used
 735       in a compare operation.
 736
 737   6.  m  Make
 738
 739       The attribute permission "m" is required for all
 740       attributes that are placed on an object when it is
 741       created. Just as the "w" and "o" permissions are used
 742       in the Modify operation, the "m" permission is used in
 743       the Add operation. Additionally, note that "w" and "o"
 744       have no bearing on the Add operation and "m" has no
 745       bearing on the Modify operation.  Since a new object
 746       does not yet exist, the "a" and "m" permissions needed
 747       to create it must be granted on the new object's
 748       parent. This differs from "w" and "o" which must be
 749       granted on the object being modified. The "m"
 750       permission is distinct and separate from the "w" and
 751       "o" permissions so that there is no conflict between
 752       the permissions needed to add new children to an entry
 753       and the permissions needed to modify existing children
 754       of the same entry.
 755
 756 Note:  Modify-replace values of an attribute requires "w"
 757 and "o" permission.
 758
 759 Permissions that apply to an entire entry:
 760
 761
 762    a    Add        Add an entry below this entry
 763
 764
 765
 766 Stokes, et al      Expires 14 January 2001         [Page 12]
 767 \f
 768
 769
 770
 771
 772 Internet-Draft      Access Control Model        14 July 2000
 773
 774
 775
 776    d    Delete     Delete this entry
 777    e    Export     Export entry & subordinates to new
 778                       location
 779    i    Import     Import entry & subordinates from some
 780                       location
 781    n    RenameDN   Rename an entry's DN
 782    b    BrowseDN   Browse an entry's DN
 783    t    ReturnDN   Allows DN of entry to be disclosed in
 784                       an operation result
 785
 786
 787   1.  a  Add
 788
 789       If granted, permits creation of an entry in the DIT
 790       subject to control on all attributes and values to be
 791       placed in the new entry at time of creation.  In order
 792       to add an entry, permission must also be granted to
 793       add at least the mandatory attributes.
 794
 795   2.  d  Delete
 796
 797       If granted, permits the entry to be removed from the
 798       DIT regardless of controls on attributes within the
 799       entry.
 800
 801   3.  e  Export
 802
 803       If granted, permits an entry and its subordinates (if
 804       any) to be exported; that is, removed from the current
 805       location and placed in a new location subject to the
 806       granting of suitable permission at the destination.
 807       If the last RDN is changed, Rename is also required at
 808       the current location. In order to export an entry or
 809       its subordinates, there are no prerequisite
 810       permissions to contained attributed, including the RDN
 811       attributes; this is true even when the operation
 812       causes new attribute values to be added or removed as
 813       the result of the changes of RDN.
 814
 815   4.  i  Import
 816
 817       If granted, permits an entry and its suordinates (if
 818       any) to be imported; that is, removed from some other
 819       location and placed a t the location to which the
 820       permission applies subject to the granting of suitable
 821       permissions at the source location.  In order to
 822       import an entry or its subordinates, there are no
 823       prerequisite permissions to contained attributed,
 824       including the RDN attributes; this is true even when
 825       the operation causes new attribute values to be added
 826       or removed as the result of the changes of RDN.
 827
 828
 829
 830 Stokes, et al      Expires 14 January 2001         [Page 13]
 831 \f
 832
 833
 834
 835
 836 Internet-Draft      Access Control Model        14 July 2000
 837
 838
 839
 840   5.  n  RenameDN
 841
 842       Granting Rename is necessary for an entry to be
 843       renamed with a new RDN, taking into account
 844       consequential changes to the distinguished names of
 845       subordinate entries, if any; if the name of the
 846       superior is unchanged, the grant is sufficient.  In
 847       order to rename an entry, there are no prerequisite
 848       permissions to contained attributed, including the RDN
 849       attributes; this is true even when the operation
 850       causes new attribute values to be added or removed as
 851       the result of the changes of RDN.
 852
 853   6.  b  BrowseDN
 854
 855       If granted, permits entries to be accessed using
 856       directory operations which do not explicitly provide
 857       the name of the entry.
 858
 859   7.  t  ReturnDN
 860
 861       If granted, allows the distinguished name of the entry
 862       to be disclosed in the operation result.
 863
 864 All permissions (for grant and deny) for an attribute/entry
 865 and a given subject MUST be contained within one ldapACI
 866 value, i.e. (in abbreviated form)
 867
 868  ldapACI:  ...grant OID.attr1 subjectA
 869  ldapACI:  ...deny OID.attr1 subjectA
 870
 871 must be ldapACI:  ...grant ... deny... OID.attr1 subjectA
 872
 873 Using the defined BNF it is possible for the permission
 874 string to be empty. The ACI
 875
 876  ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US
 877
 878  ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US
 879
 880 means that this group (Dept XYZ) is granted permission to
 881 read and search all attributes except OID.attr1 because
 882 OID.attr1 is more specific than "[all]".
 883
 884
 885 4.2.3  Attributes
 886
 887 Attribute describes an attribute name in the form of a
 888 dotted decimal OID for that <attr>. If the string (OID)
 889 refers to an attribute not defined in the given server's
 890 schema, the server SHOULD report an error. "[entry]" means
 891
 892
 893
 894 Stokes, et al      Expires 14 January 2001         [Page 14]
 895 \f
 896
 897
 898
 899
 900 Internet-Draft      Access Control Model        14 July 2000
 901
 902
 903
 904 the permissions apply to the entire object. This could mean
 905 actions such as delete the object, or add a child object.
 906 "[all]" means the permission set apply to all attributes of
 907 the entry.
 908
 909 If the keyword "[all]" and another attribute are both
 910 specified within an ACI, the more specific permission set
 911 for the attribute overrides the less specific permission set
 912 for "[all]".
 913
 914
 915 4.2.4  Subjects and Associated Authentication
 916
 917 The following subjects are defined and MUST be supported:
 918
 919    - authzID, defined per [authmeth]
 920
 921    - group, defined as the distinguished name of a
 922      groupOfNames or groupOfUniqueNames entry
 923
 924    - role
 925
 926    - subtree, defined as the distinguished name of a non-
 927      leaf node in the DIT
 928
 929    - ipAddress,
 930
 931    - public, defined as public access
 932
 933    - this, defined as the user whose name matches that of
 934      the entry being accessed
 935
 936 Other parties MAY define other subjects.  It is the
 937 responsibility of those parties to provide the definition.
 938
 939 A subject may be qualified by the type of authentication
 940 required for access to a given attribute(s) or entry.  If no
 941 authnLevel is present, then no specific type of
 942 authentication is additionally required for access.  If
 943 authnLevel is specified, then that type of authentication is
 944 additionally required for access.  The authnLevels parallel
 945 the authentication mechanisms specified for LDAPv3:  simple,
 946 SASL (any type of SASL mechanism), and a SASL-specific
 947 mechanism.  The authnLevel of is not an acceptable mechanism
 948 for this case) as part of obtaining access.
 949
 950
 951 4.3  Grant/Deny Evaluation Rules
 952
 953 The decision whether to grant or deny a client access to a
 954 particular piece of information is based on several pieces
 955
 956
 957
 958 Stokes, et al      Expires 14 January 2001         [Page 15]
 959 \f
 960
 961
 962
 963
 964 Internet-Draft      Access Control Model        14 July 2000
 965
 966
 967
 968 of information found within the ldapaci value.  Throughout
 969 the decision making process, there are guiding principals.
 970
 971    - Specificity: More specific policies MUST override less
 972      specific ones (e.g. individual user entry in ACI takes
 973      precedence over group entry).
 974
 975    - Deny takes precedence over Grant.
 976
 977    - When there are conflicting ACI values, deny takes
 978      precedence over grant.
 979
 980    - Deny is the default when there is no access control
 981      information.
 982
 983 Precendence of Scope Types (highest to lowest)
 984
 985    - entry
 986
 987    - subtree
 988
 989 Precedence of Subjects within a Scope (highest to lowest):
 990
 991    - ipAddress
 992
 993    - authzID, this
 994
 995    - group, role, this, public
 996
 997    - subtree, public
 998
 999 Although other types MAY be defined given the BNF, use of
1000 the well-known types aids in interoperability and
1001 operational consistency.
1002
1003 Access Decision algorithm:
1004
1005   1.  Determine all the ldapACI values which could apply to
1006       the target DN which is being accessed.  This is the DN
1007       of the entry which is being queried in a search,
1008       modified, deleted, etc.  When determining all the
1009       ldapACI values, the scope field should be used. All
1010       ldapACI values with a scope of 'entry' take precedence
1011       over ldapACI values with a scope of 'subtree'.
1012
1013   2.  Determine which ldapACI (of the set determined in step
1014       1) apply to the bound DN.  This is determined by
1015       looking at the subject (combination of subject type
1016       and subject value) and bind type.  If no bind is in
1017       effect (this is possible in ldapv3), then treat this
1018       lack of bind as if bound as anonymous.  Start with the
1019
1020
1021
1022 Stokes, et al      Expires 14 January 2001         [Page 16]
1023 \f
1024
1025
1026
1027
1028 Internet-Draft      Access Control Model        14 July 2000
1029
1030
1031
1032       most specific subject type.  If at any time, at least
1033       one ldapACI value exists for a specificity level, then
1034       processing stops; the exception here is 'this' because
1035       this may also be combined with group to use power of
1036       'this'.   Evaluation should take place on set of
1037       ldapACI values which are all of the same specificity
1038       level.  Subjects of the same precedence are combined
1039       using union semantics.
1040
1041   3.  Evaluate the remaining ldapACI values and determine a
1042       grant/deny decision.  If conflicting ldapACI value
1043       exists for the same attribute, or attributes (i.e. one
1044       ldapACI grants permission and another denies
1045       permission), then deny takes precedence over grant.
1046       For example, if one is granted permission to
1047       "objectclass" in one ldapACI value by being a member
1048       of group cn=Admin, and denied permission by being a
1049       member of cn = NontrustedAdmins, then the bound user
1050       would not receive permission to objectclass.
1051
1052       The rule of specificity also applies to the
1053       attributes. If one is denied permission to "[ all ]"
1054       attributes, but granted permission to "objectclass"
1055       then the more specific value of  "objectclass" takes
1056       precedence over the less specific value of "[ all ] ".
1057       In this case the user would be granted permission to
1058       "objectclass" but denied permission to all other
1059       attributes.
1060
1061
1062
1063 5.  Required Permissions for each LDAP Operation
1064
1065 This section defines the required permissions for each LDAP
1066 operation but even if these requirements are satisfied the
1067 server MAY refuse to carry out the operation due to other
1068 implementation specific security considerations. For
1069 example, a server may refuse to modify an entry because the
1070 database where that entry resides is in read only mode.
1071 Another example might be that although the access control is
1072 available to the userPassword attribute a server may refuse
1073 modifications due to some server specific policy governing
1074 access to passwords.
1075
1076 Here, we specify the rights required by a user when
1077 performing an LDAP operation in terms of the LDAP
1078 permissions specified in section 6.1.  Recall that  "a, d,
1079 e, i, n, b,t" are permissions that apply to entries as a
1080 whole while permissions "r, s, w, o, c, m" apply to
1081 attributes within entries.
1082
1083
1084
1085
1086 Stokes, et al      Expires 14 January 2001         [Page 17]
1087 \f
1088
1089
1090
1091
1092 Internet-Draft      Access Control Model        14 July 2000
1093
1094
1095
1096 Required permissions for LDAP extended operations and LDAP
1097 controls are beyond the scope of this draft.
1098
1099 There is a requirement that a user should not be able to
1100 infer the existence of data in the Directory, if the user
1101 does not have the required access rights to that data.  An
1102 example of this requirement would be in a hosting
1103 environment where you would not want any users from the coke
1104 subtree to be able to even discover that the pepsi tree was
1105 hosted on the same server.  This "discloseOnError" feature
1106 will be set once for server in the rootDSE advertised by the
1107 attribute discloseOnError.  The default for discloseOnError
1108 is false (0).  The lack of this attribute in the rootDSE is
1109 interpreted as the default.  The details of its effects are
1110 addressed below, operation by operation.
1111
1112 For the following, assume that the authorization identity of
1113 the user doing the operation is authzID.
1114
1115
1116 5.1  Bind Operation
1117
1118 This draft does not require any permissions to allow a bind
1119 operation to proceed.
1120
1121
1122 5.2  Search Operation
1123
1124 Recall that the parameters of the Search operation per RFC
1125 2251 [LDAPv3] Section 4.5 are:
1126
1127    SearchRequest ::= [APPLICATION 3] SEQUENCE {
1128         baseObject      LDAPDN,
1129         scope           ENUMERATED {
1130                 baseObject              (0),
1131                 singleLevel             (1),
1132                 wholeSubtree            (2) },
1133         derefAliases    ENUMERATED {
1134                 neverDerefAliases       (0),
1135                 derefInSearching        (1),
1136                 derefFindingBaseObj     (2),
1137                 derefAlways             (3) },
1138         sizeLimit       INTEGER (0 .. maxInt),
1139         timeLimit       INTEGER (0 .. maxInt),
1140         typesOnly       BOOLEAN,
1141         filter          Filter,
1142         attributes      AttributeDescriptionList }
1143
1144 Suppose a server is processing a search request from user
1145 authzID with parameters as above and is processing the entry
1146 with dn candidateDN to decide if it may be returned or not.
1147
1148
1149
1150 Stokes, et al      Expires 14 January 2001         [Page 18]
1151 \f
1152
1153
1154
1155
1156 Internet-Draft      Access Control Model        14 July 2000
1157
1158
1159
1160 Then the permissions required by authzID that need to be
1161 evaluated are as follows:
1162
1163
1164   1.  permission "b" to the entry candidateDN
1165
1166       If this permission is not granted then the dn
1167       candidateDN MUST not be returned nor any attribute
1168       type nor attribute value from this entry.
1169
1170       If this permission is granted then the dn candidateDN
1171       MAY be returned.
1172
1173       Note: The idea of the "b" permission is to say "a user
1174       has discovery rights" at a certain entry in the
1175       directory.  Assuming that the further required
1176       permissions below are satisfied then having "b" right
1177       is enough to allow the server to return candidateDN.
1178       Of course candidateDN contains in it's components,
1179       attributes and attribute values for all the ancestors
1180       of candidateDN.  This can lead to the slightly odd
1181       situation that we can discover the naming attribute of
1182       an entry and that attribute's value by virtue of
1183       having the required searching permissions to it's
1184       child but not by searching the entry directly.
1185
1186   2.  permission "s" to each attribute appearing in a
1187       presence test during the evaluation of the search
1188       filter.  permission "r" to each attribute appearing in
1189       non-presence tests (see rfc1960, section 3:
1190       equalityMatch, substrings, greaterOrEquial,
1191       lessOrEqual, present, approxMatch, extensibleMatch)
1192       during the evaluation of the search filter.
1193
1194       The above statement covers the case where the
1195       attributes are being evaluated as part of an
1196       extensibleMatch (RFC 2251 section 4.5.1) which appears
1197       in the filter.  In the case where the dnAttributes
1198       field of the extensibleMatch is true then we do not
1199       require any access checks to the attributes of the dn
1200       candidateDN as access to these is taken to be granted
1201       by the "b" permission, which has already been required
1202       above.
1203
1204       If there is an attribute in a filter element to which
1205       the required permission is not granted then that
1206       filter element evaluates to "Undefined" of the three-
1207       valued-logic of X.511(93).
1208
1209       Note A: Although both "r" and "s" permissions will
1210       typically be granted to attributes we keep both
1211
1212
1213
1214 Stokes, et al      Expires 14 January 2001         [Page 19]
1215 \f
1216
1217
1218
1219
1220 Internet-Draft      Access Control Model        14 July 2000
1221
1222
1223
1224       permissions as there are cases where the distinction
1225       is useful.  For example, the ability to grant the
1226       right to discover that a user entry contains a
1227       userPassword attribute, but not to read it's value
1228       ("s" but not "r").  The converse, granting "r" but not
1229       "s" permission is less easy to motivate.
1230
1231       Note B: There is an unusual behaviour with respect to
1232       naming attributes illustrated in the following
1233       example:
1234
1235       Suppose I have "b" rights to cn=fred,o=sun.com and "r"
1236       rights to attribute objectclass but not "r" rights to
1237       cn then with search filter (objectclass=*) I get back
1238       the dn and objectclass (and so can see the value of
1239       cn), but with a search filter of (cn=fred) I do not
1240       get anything.
1241
1242   3.  permission "r" to each attribute in the attribute list
1243
1244       AttributeDescriptionList (or all attributes in the
1245       entry candidateDN if AttributeDescriptionList is *)
1246       whose type and/or value will be returned.
1247
1248       Note: The presence of an attribute in an entry is only
1249       ever volunteered by the server if "r" permission is
1250       granted to it, though a user may infer the presence of
1251       an attribute with "s" permission by using a presence
1252       test on that attribute in the search filter.
1253
1254   4.  permission "t" to the entry candidateDN
1255
1256       If this permission is not granted then the dn
1257       candidateDN MUST NOT be returned. If the server knows
1258       of an alias for the entry, this alias may be returned
1259       instead. If no alias name is available then the entry
1260       candidateDN MUST be omitted from the search results.
1261
1262
1263   5.  Disclose on error for the Search operation
1264
1265       If every entry in the scope of the search fails to
1266       satisfy item 1 (browse right on the candidate entry)
1267       or item 2 (right to use the filter on that entry) and
1268       if discloseOnError is not granted to the baseObject
1269       entry then the operation MUST fail with a "no such
1270       object error" and the matchedDN of the LDAPResult MUST
1271       be set to "". If every entry in the scope of the
1272       search fails to satisfy items 1 or 2 above and
1273       discloseOnError is granted to the baseObject then the
1274       empty set of results is returned.
1275
1276
1277
1278 Stokes, et al      Expires 14 January 2001         [Page 20]
1279 \f
1280
1281
1282
1283
1284 Internet-Draft      Access Control Model        14 July 2000
1285
1286
1287
1288 5.3  Modify Operation
1289
1290 Recall that the parameters of the Modify operation per
1291 RFC2251 [LDAPv3] Section 4.6 are:
1292
1293    ModifyRequest ::= [APPLICATION 6] SEQUENCE {
1294         object          LDAPDN,
1295         modification    SEQUENCE OF SEQUENCE {
1296                 operation  ENUMERATED {
1297                                    add     (0),
1298                                    delete  (1),
1299                                    replace (2) },
1300                 modification    AttributeTypeAndValues } }
1301
1302
1303    AttributeTypeAndValues ::= SEQUENCE {
1304         type    AttributeDescription,
1305         vals    SET OF AttributeValue }
1306
1307 Then the permissions required by authzID that need to be
1308 evaluated are as follows:
1309
1310
1311   1.  permission "w" to each attribute being added to object
1312
1313       If this permission is not granted to such an
1314       attribute, then the operation MUST fail.  In this
1315       case, if discloseOnError is not granted to the entry
1316       then "no such object" error is returned; if
1317       discloseOnError is granted to the entry and a
1318       duplicate attribute value is being added then
1319       "attribute value already exists" error is returned; if
1320       discloseOnError is granted to the entry and no
1321       duplicate value is being added then an "insufficient
1322       access" error is returned.
1323
1324   2.  permission "o" to each attribute for which a value is
1325       being deleted from object
1326
1327       If this permission is not granted to such an attribute
1328       then the operation MUST fail.  In this case, if
1329       discloseOnError is not granted to the entry then "no
1330       such object" error is returned; if discloseOnError is
1331       granted to the entry and the attribute or one of the
1332       values to be deleted does not exist then a "no such
1333       attribute or value" error is returned; if
1334       discloseOnError is granted to the entry and the
1335       attribute and all values specified to be deleted exist
1336       then an "insufficient access" error is returned.
1337
1338
1339
1340
1341
1342 Stokes, et al      Expires 14 January 2001         [Page 21]
1343 \f
1344
1345
1346
1347
1348 Internet-Draft      Access Control Model        14 July 2000
1349
1350
1351
1352   3.  permissions "o" and "w" to each attribute being
1353       replaced in object
1354
1355       If one of these these permissions is not granted to
1356       such an attribute then the operation MUST fail.  In
1357       this case, if discloseOnError is not granted to the
1358       entry then a "no such object" error is returned; if
1359       discloseOnError is granted to the entry then
1360       "insufficient access" error is returned.
1361
1362
1363 5.4  Add Operation
1364
1365 Recall that the parameters of the Add operation per RFC2251
1366 [LDAPv3] Section 4.7 are:
1367
1368    AddRequest ::= [APPLICATION 8] SEQUENCE {
1369         entry           LDAPDN,
1370         attributes      AttributeList }
1371
1372
1373    AttributeList ::= SEQUENCE OF SEQUENCE {
1374         type    AttributeDescription,
1375         vals    SET OF AttributeValue }
1376
1377 Then the permissions required by authzID that need to be
1378 evaluated are as follows:
1379
1380       permission "a" to the parent of entry
1381
1382       The access rights required for the creation of a root
1383       entry in the Directory are beyond the scope of this
1384       document.  They will be vendor specific.
1385
1386   1.  permission "m" to the parent of entry for each
1387       attribute being added to entry
1388
1389 If any of these permissions are not granted then the
1390 operation MUST fail.  In this case if discloseOnError is on
1391 and the entry to be added does not already exist then
1392 "insufficient access" is returned.  If it does exist then
1393 "Entry already exists" is returned.  If discloseOnError is
1394 off then "No such object" is returned (meaning the parent
1395 object).
1396
1397 If they are all granted then the operation MAY proceed.
1398
1399 Note: We require "m" permission to each attribute to prevent
1400 an entry from aquiring "unintended" rights (via group or
1401 role membership),  to stop a "rogue" ACI being added that
1402 would prevent even admins deleting the entry and general
1403
1404
1405
1406 Stokes, et al      Expires 14 January 2001         [Page 22]
1407 \f
1408
1409
1410
1411
1412 Internet-Draft      Access Control Model        14 July 2000
1413
1414
1415
1416 consistency with the MODIFY operation.
1417
1418 Note: The access rights required for the creation of the
1419 first entry in the directory are beyond the scope of this
1420 document.
1421
1422
1423 5.5  Delete Operation
1424
1425 Recall that the parameters of the Delete operation per
1426 RFC2251 [LDAPv3] Section 4.10 are:
1427
1428     DelRequest ::= [APPLICATION 10] LDAPDN
1429
1430 Then the permissions required by authzID that need to be
1431 evaluated are as follows:
1432
1433
1434   1.  permission "d" to the entry in the Delete request
1435
1436 If this permission is not granted, then the operation MUST
1437 fail.  In this case if discloseOnError is on and the entry
1438 to be deleted exists then "insufficient access" is returned.
1439 If it does not exist then "No such Object" is returned.  If
1440 discloseOnError is off then "No such object" is returned
1441 (meaning the parent object).
1442
1443 If this permission is granted, then the operation MAY
1444 proceed.
1445
1446 Note: One could also require the "o" permission to be
1447 granted to allow the operation to proceed, but customer
1448 experience has shown that the requirement of the additional
1449 permission is not useful nor expected, and X.500 requires
1450 only the "d" permission.
1451
1452
1453 5.6  Modify DN Operation
1454
1455 Recall that the parameters of the Modify DN operation per
1456 RFC2251 [LDAPv3] Section 4.6 are:
1457
1458    ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
1459         entry           LDAPDN,
1460         newrdn          RelativeLDAPDN,
1461         deleteoldrdn    BOOLEAN,
1462         newSuperior     [0] LDAPDN OPTIONAL }
1463
1464 Then the permissions required by authzID that need to be
1465 evaluated are as follows:
1466
1467
1468
1469
1470 Stokes, et al      Expires 14 January 2001         [Page 23]
1471 \f
1472
1473
1474
1475
1476 Internet-Draft      Access Control Model        14 July 2000
1477
1478
1479
1480   1.  If newSuperior is not present (ie. only the RDN is
1481       being renamed) then permission "n" to entry is
1482       required.
1483
1484   2.  If newSuperior is present then permission "e" to entry
1485       and permission "i" to newSuperior are required.
1486
1487 If any of these permissions are not granted then the
1488 operation MUST fail.  In this case, if discloseOnError is on
1489 then an "insufficient access error" is returned.  Otherwise,
1490 "No  such object" is returned.
1491
1492 If they are all granted then the operation MAY proceed.
1493
1494 Note A: We do not require any additional permissions in the
1495 case where deleteoldrdn is TRUE.
1496
1497 Note B: These permissions allow the naming attribute of an
1498 entry (or entries) to be changed even though "o" and "w"
1499 permissions are not available on the entry.  Distinguishing
1500 the permissions like this allows us to grant permissions for
1501 the ModifyDN operation, but not the Modify operation and
1502 vice versa.
1503
1504
1505 5.7  Compare Operation
1506
1507 Recall that the parameters of the Compare operation per
1508 RFC2251 [LDAPv3] Section 4.10 are:
1509
1510    CompareRequest ::= [APPLICATION 14] SEQUENCE {
1511         entry           LDAPDN,
1512         ava             AttributeValueAssertion }
1513
1514 Then the permissions required by authzID that need to be
1515 evaluated are as follows:
1516
1517
1518   1.  permission "c" to the attribute in entry on which the
1519       comparison is being made.
1520
1521 If any of these permissions are not granted then the
1522 operation MUST fail.  In this case, if discloseOnError is on
1523 then an "insufficient access error" is returned.  Otherwise,
1524 "No  such object" is returned.
1525
1526 If they are all granted then the operation MAY proceed.
1527
1528
1529
1530
1531
1532
1533
1534 Stokes, et al      Expires 14 January 2001         [Page 24]
1535 \f
1536
1537
1538
1539
1540 Internet-Draft      Access Control Model        14 July 2000
1541
1542
1543
1544 5.8  Abandon Operation
1545
1546 Recall that the parameters of the Abandon operation per
1547 RFC2251 [LDAPv3] Section 4.6 are:
1548
1549    AbandonRequest ::= [APPLICATION 16] MessageID
1550
1551 authzID always has the right to send an Abandon Operation
1552 for an operation he previously initiated.
1553
1554
1555 5.9  Extended Operation
1556
1557 Recall that the parameters of the Extended operation per
1558 RFC2251 [LDA{v3] Section 4.12 are:
1559
1560    ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
1561         requestName      [0] LDAPOID,
1562         requestValue     [1] OCTET STRING OPTIONAL }
1563
1564 The access required for an Extended Operation is beyond the
1565 scope of this document.  The required access will normally
1566 be defined by the implementor of the extended request.
1567
1568
1569
1570 6.  Required Permissions for Handling Aliases and References
1571
1572
1573 Use of aliases and referrals are part of LDAPv3.  However,
1574 neither is particularly well-defined.  Alias
1575 objects/attributes are defined in RFC 2256 as derived from
1576 X.500, but LDAPv3 does not explicitly define its semantics
1577 or behavior.  X.500 does define alias semantics and behavior
1578 with respect to access control; we define its behavior in
1579 LDAPv3 based on the X.511, section 7.11.1.  Referrals and
1580 knowledge information are still under design in LDAPv3; they
1581 are defined in X.500, however, X.500 punts on their
1582 semantics and behavior with respect to access control.  We
1583 define their semantics and behavior in LDAPv3 in terms that
1584 should be independent of the future LDAPv3 definition of
1585 referrals and knowledge information.
1586
1587
1588 6.1  ACI Distribution
1589
1590 Currently there is no LDAP standard defining how to
1591 distribute directory data between LDAP servers. Consequently
1592 this draft cannot fully specify the behavior of the Access
1593 Control Model in a distributed environment. The case of
1594 distribution via referrals is treated in the "Referrals"
1595
1596
1597
1598 Stokes, et al      Expires 14 January 2001         [Page 25]
1599 \f
1600
1601
1602
1603
1604 Internet-Draft      Access Control Model        14 July 2000
1605
1606
1607
1608 section below. In the case of chaining (where one LDAP
1609 server forwards a request to another on behalf of a client)
1610 then it is server specific how the access control model
1611 behaves in this environment. Similarly it is server specific
1612 how the server determines whether the chaining of an
1613 operation is permitted in the first place. For example, the
1614 implementation may choose to regard the local naming context
1615 and the remote subordinate naming context as seperate Access
1616 Control Specific Areas, or it may regard the DIT as one
1617 Access Control Specific Area and implement mechanisms to
1618 propagate access control information between the two
1619 servers. The behavior of the Access Control Model in
1620 distributed environments such as these is beyond the scope
1621 of this draft.
1622
1623
1624 6.2  Aliases
1625
1626 There are two things to protect with respect to aliases:
1627 the real name of the aliased object and the location of the
1628 server holding it.
1629
1630 If alias de-referencing is required in the process of
1631 locating a target entry, no specifc permissions are
1632 necessary for alias de-referencing to take place. Access
1633 control is enforced at the object pointed to by the alias.
1634
1635 If alias de-referencing would result in a
1636 continuationReference (e.g. from a search operation), then
1637 browse permission is required to the alias entry and read
1638 permission is required to the 'aliasedObjectName' attribute.
1639 Requiring these permission closes the hole of discovery.
1640
1641
1642 6.3  Referrals
1643
1644 If a referral is to be followed, no specifc permissions are
1645 necessary for the ldap client to follow the referral. Access
1646 control is enforced at the referenced object.  If a referral
1647 is returned, then browse is required on the entry and read
1648 permission is required to the attribute containing the
1649 referral (we cannot name this attribute exactly today
1650 because there are no RFCs on this - only drafts). If the
1651 server implements a default referral, then no special
1652 permissions are required to read and return that referral.
1653 Requiring these permissions closes the hole of discovery.
1654 In the default case, it is assumed that a default referral
1655 is public.
1656
1657
1658
1659
1660
1661
1662 Stokes, et al      Expires 14 January 2001         [Page 26]
1663 \f
1664
1665
1666
1667
1668 Internet-Draft      Access Control Model        14 July 2000
1669
1670
1671
1672 7.  Controlling Access to Access Control Information
1673
1674 The ldapACI attribute is used to specify control for who has
1675 permission to set/change access control information
1676 (ldapACI).  The ldapACI attribute/OID is just another
1677 attribute described with a scope, set of rights and
1678 permissions, and subject as a value of the ldapACI
1679 attribute.  (See the example in the "ACI Examples" section).
1680
1681 If the policy for controlling the ldapACI attribute is not
1682 specified for any object in the tree, behavior is
1683 implementation defined. For instance, if no object anywhere
1684 in the tree defines the access for ldapACI within the
1685 ldapACI attribute, then the server could simply assert that
1686 the 'root DN' is considered the policy owner (controller for
1687 controlling access control) for all objects.
1688
1689
1690
1691 8.  ACI Examples
1692
1693 Note that in the examples, the form "OID.<attrname>" refers
1694 to the OID in dotted decimal form for the attribute
1695 <attrname>.  This shorthand notation is used only for the
1696 examples.  In implementation, the dotted decimal form of the
1697 OID is used.
1698
1699
1700 8.1  Attribute Definition
1701
1702 The following examples show the access required to control
1703 access to the ldapACI attribute.  The first example shows
1704 controlling the access control on an individual entry and
1705 its attributes.  The second example shows controlling the
1706 access control on a subtree.
1707
1708  ldapACI: entry#grant:r,w#
1709     OID.ldapACI#authnLevel:any:role:cn=aciAdmin
1710
1711  ldapACI: subtree#grant:r,w#
1712     OID.ldapACI#authnLevel:any:role:cn=aciAdmin
1713
1714 The next example shows a ldapACI attribute where a group
1715 "cn=Dept XYZ, c=US" is being given permissions to read,
1716 search, and compare attribute attr1. The permission applies
1717 to the entire subtree below the node containing this ACI.
1718 Authentication of a specified type is not required.
1719
1720  ldapACI:subtree#grant;r,s,c#
1721       OID.attr1#group:cn=Dept XYZ,c=US
1722
1723
1724
1725
1726 Stokes, et al      Expires 14 January 2001         [Page 27]
1727 \f
1728
1729
1730
1731
1732 Internet-Draft      Access Control Model        14 July 2000
1733
1734
1735
1736 The next example shows an ACI attribute where a role
1737 "cn=SysAdmins,o=Company" is being given permissions to add
1738 objects below this node and read, search, and compare
1739 attributes attr2 and attr3. The permission applies to the
1740 entire subtree below the node containing this ACI.
1741
1742  ldapACI: subtree#grant:a#
1743             [entry]#role:cn=SysAdmins,o=Company
1744
1745  ldapACI: subtree#grant:r,s,c#
1746             OID.attr2#role:cn=SysAdmins,o=Company
1747
1748  ldapACI: subtree#grant:r,s,c#
1749             OID.attr3#role:cn=SysAdmins,o=Company
1750
1751
1752 8.2  Modifying the ldapACI Values
1753
1754 Modify-Replace works as defined in the ldap operation
1755 modify. If the attribute value does not exist, create the
1756 value. If the attribute does exist, replace the value.  If
1757 the ldapACI value is replaced, all ldapACI values are
1758 replaced.
1759
1760 A given ldapACI for an entry:
1761
1762  ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC
1763
1764  ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
1765
1766 perform the following change:
1767
1768   dn: cn=someEntry
1769   changetype: modify
1770   replace: ldapACI
1771   ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
1772
1773 The resulting ACI is:
1774
1775 ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
1776
1777 ( ldapACI values for Dept XYZ and ABC are lost through the
1778 replace )
1779
1780 During an ldapmodify-add, if the ACI does not exist, the
1781 create the ACI with the specific ldapACI value(s).  If the
1782 ACI does exist, then add the specified values to the given
1783 ldapACI.  For example a given ACI:
1784
1785 ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
1786
1787
1788
1789
1790 Stokes, et al      Expires 14 January 2001         [Page 28]
1791 \f
1792
1793
1794
1795
1796 Internet-Draft      Access Control Model        14 July 2000
1797
1798
1799
1800 with a modification:
1801
1802   dn: cn=someEntry
1803   changetype: modify
1804   add: ldapACI
1805   ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
1806
1807 would yield an multi-valued ACI of:
1808
1809  ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
1810
1811  ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
1812
1813 To delete a particular ACI value, use the regular ldapmodify
1814 - delete syntax
1815
1816 Given an ACI of:
1817
1818  ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
1819  ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
1820
1821   dn: cn = some Entry
1822   changetype: modify
1823   delete: ldapACI
1824   ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
1825
1826 would yield a remaining ACI on the server of
1827
1828 ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
1829
1830 The attributes which are defined for access control
1831 interchange may be used in all LDAP operations.
1832
1833 Within the ldapmodify-delete operation, the entire acl may
1834 be deleted by specifying
1835
1836  dn: cn = some Entry
1837  changetype: modify
1838  delete: ldapACI
1839
1840 In this case, the entry would then inherit its ACI from some
1841 other node in the tree depending on the server inheritance
1842 model.
1843
1844 Similarly, if all values of ldapACI are deleted, then the
1845 access control information for that entry is defined by that
1846 implementation's inheritance model.
1847
1848
1849
1850
1851
1852
1853
1854 Stokes, et al      Expires 14 January 2001         [Page 29]
1855 \f
1856
1857
1858
1859
1860 Internet-Draft      Access Control Model        14 July 2000
1861
1862
1863
1864 8.3  Evaluation
1865
1866 These examples assume that the ldapACI entries listed in
1867 each example are the only ACI which applies to the entry in
1868 question; if backing-store ACI also exists, the effective
1869 policy may be different from that listed in each example.
1870 See section 10 for a discussion of the semantics of ldapACI
1871 entries when backing-store ACI administration is also used.
1872
1873 Assume cn=jsmith is a member of group cn=G1.  Assume
1874 cn=jsmith is a member of group cn=G2.
1875
1876  Example #1
1877  dn: o=XYZ, c=US
1878  ldapACI: subtree#grant:r#attr1
1879             #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
1880  ldapACI: subtree#grant:w#attr1
1881             #group:cn=G1,ou=ABC,o=XYZ,c=US
1882
1883  What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
1884  Read (r) access; authzID is higher precedence than
1885  group.
1886
1887
1888  Example #2
1889  dn: o=XYZ, c=US
1890  ldapACI: subtree#grant:r#attr2
1891             #group:cn=G1,ou=ABC,o=XYZ,c=US
1892  ldapACI: subtree#grant:w#attr2
1893             #group:cn=G2,ou=ABC,o=XYZ,c=US
1894
1895  What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
1896  Read-write (r,w) access; ACI is combined because both
1897  subjects (group) have same precedence.
1898
1899
1900  Example #3
1901  dn: o=XYZ, c=US
1902  ldapACI: subtree#grant:r,w#attr3
1903             #group:cn=G1,ou=ABC,o=XYZ,c=US
1904  ldapACI: subtree#deny:w#attr3#group:cn=G2,ou=ABC,o=XYZ,c=US
1905
1906  What rights does cn=jsmith have to attr3 of o=XYZ, c=US?
1907  Read access; write is denied (deny has precedence over
1908  grant).
1909
1910
1911  Example #4
1912  dn: o=XYZ, c=US
1913  ldapACI: subtree#grant:w#attr4
1914             #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
1915
1916
1917
1918 Stokes, et al      Expires 14 January 2001         [Page 30]
1919 \f
1920
1921
1922
1923
1924 Internet-Draft      Access Control Model        14 July 2000
1925
1926
1927
1928  ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US
1929
1930  What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
1931  Write (w); rights given to an authzID take precedence
1932  over those given to a subtree.
1933
1934
1935  Example #5
1936  dn: o=XYZ, c=US
1937  ldapACI: subtree#grant:m#OID.attr5
1938             #authzID-dn:cn=jsmith,o=ABC,c=US
1939  ldapACI: subtree#grant:m#OID.cn
1940             #authzID-dn:cn=jsmith,o=ABC,c=US
1941  ldapACI: subtree#grant:m#OID.sn
1942             #authzID-dn:cn=jsmith,o=ABC,c=US
1943  ldapACI: subtree#grant:a#[entry]
1944             #authzID-dn:#cn=jsmith,o=ABC,c=US
1945
1946  What rights does cn=jsmith have to o=XYZ, c=US?
1947  Make(m) on attributes attr5, cn, and sn and Add(a)
1948  on the entry.  These are the minimal yet sufficient
1949  permissions to create a new object,
1950  cn=New, o=XYZ, c=US with values for the attr5, cn,
1951  and sn attributes.  This example illustrates how the
1952  "m" permission can be used to limit the attributes
1953  that can be created on a new entry.
1954
1955  Example #6
1956  dn: c=US
1957  ldapACI: subtree#grant:m#[all]#subtree:c=US
1958  dn: o=XYZ, c=US
1959  ldapACI: subtree#grant:a#[entry]#
1960             authzID-dn:cn=jsmith,o=ABC,c=US
1961
1962  What rights does cn=jsmith have to o=XYZ, c=US?
1963  Make(m) on attributes all attributes and Add(a) on the
1964  entry. These are sufficient permissions to create a new
1965  object, cn=New, o=XYZ, c=US with values any desired
1966  attributes.  For administrators who do not wish to limit
1967  the attributes that can be created on new entries, this
1968  example shows how a single ldapACI at the top of the
1969  domain solves the problem.
1970
1971
1972
1973 9.  Operational Semantics of Access Control Operations
1974
1975 The semantics of access control operations described in this
1976 document are defined operationally in terms of "histories".
1977 A history is a sequence of actions (x1, x2, ..., xN).
1978
1979
1980
1981
1982 Stokes, et al      Expires 14 January 2001         [Page 31]
1983 \f
1984
1985
1986
1987
1988 Internet-Draft      Access Control Model        14 July 2000
1989
1990
1991
1992 9.1  Types of actions
1993
1994 We consider five types of actions:
1995
1996    - LDAP Access Control Policy Update actions: invocations
1997      of ldap modify when used to add, delete, or replace the
1998      aci attribute; invocations of ldap add when used to add
1999      an entry with an aci attribute.  A LDAP Access Control
2000      Policy Update action may replace the policy (by
2001      completely replacing the aci attribute with new policy
2002      information) or it may grant or deny specific rights
2003      while leaving others unaffected.
2004
2005    - LDAP Access Control Policy Query operations:
2006      invocations of ldap search when used to retrieve the
2007      aci attribute; invocations of ldap search with the
2008      getEffectiveRightsRequest control; invocations of the
2009      ldapGetEffectiveRightsRequest extended operation.
2010
2011    - Datastore Access Control Policy Update Actions: any
2012      operation implemented by the server which LDAP is using
2013      as its datastore which changes the access policy
2014      enforced with respect to attempts to access LDAP
2015      directory entries and their attributes.
2016
2017    - LDAP Access Request operations: invocations of LDAP
2018      entry or attribute access operations (Read, Update,
2019      Search, Compare, etc...).
2020
2021    - Other operations: anything else, including Datastore
2022      operations which do not change the access policy
2023      enforced by the server.
2024
2025
2026 9.2  Semantics of Histories
2027
2028 The semantics of histories are defined as follows:
2029
2030    - LDAP Update (Replace), LDAP Query
2031
2032      The Query will show that the subject has all rights
2033      granted by the Update operation, and no rights not
2034      granted by the Update operation.
2035
2036    - LDAP Update (Grant), LDAP Query
2037
2038      The Query will show that the subject has all rights
2039      granted by the Update operation.  The Query may show
2040      that the subject also has other rights not granted by
2041      the Update operation, depending on the policy in force
2042      before the Update operation.
2043
2044
2045
2046 Stokes, et al      Expires 14 January 2001         [Page 32]
2047 \f
2048
2049
2050
2051
2052 Internet-Draft      Access Control Model        14 July 2000
2053
2054
2055
2056    - LDAP Update (Deny), LDAP Query
2057
2058      The Query will show that the subject does not have any
2059      right denied by the Update operation.  The Query may
2060      show that the subject has rights not denied by the
2061      Update operation, depending on the policy in force
2062      before the Update operation.
2063
2064    - LDAP Update (Replace), LDAP Access Request
2065
2066      The Request will succeed if it requires only rights
2067      granted to the requesting subject by the Update
2068      operation.  The Request will fail if it requires any
2069      right not granted by the Update operation.
2070
2071    - LDAP Update (Grant), LDAP Access Request
2072
2073      The Request will succeed if it requires only rights
2074      granted to the requesting subject by the Update
2075      operation.  The Request may succeed if it requires
2076      rights not granted by the Update operation, depending
2077      on the policy in force before the Update operation.
2078
2079    - LDAP Update (Deny), LDAP Access Request
2080
2081      The Request will fail if it requires any right denied
2082      to the requesting subject by the Update operation.  If
2083      the Request requires only rights which were not denied
2084      by the Update operation, it may succeed, depending on
2085      the policy in force before the Update operation.
2086
2087    - LDAP Update (Replace), Other, LDAP Query
2088
2089      The Query will show that the subject has all rights
2090      granted by the Update operation, and no rights not
2091      granted by the Update operation.
2092
2093    - LDAP Update (Grant), Other, LDAP Query
2094
2095      The Query will show that the subject has all rights
2096      granted by the Update operation.  The Query may show
2097      that the subject also has other rights not granted by
2098      the Update operation, depending on the policy in force
2099      before the Update operation.
2100
2101    - LDAP Update (Deny), Other, LDAP Query
2102
2103      The Query will show that the subject does not have any
2104      right denied by the Update operation.  The Query may
2105      show that the subject has rights not denied by the
2106      Update operation, depending on the policy in force
2107
2108
2109
2110 Stokes, et al      Expires 14 January 2001         [Page 33]
2111 \f
2112
2113
2114
2115
2116 Internet-Draft      Access Control Model        14 July 2000
2117
2118
2119
2120      before the Update operation.
2121
2122    - LDAP Update (Replace), Other, LDAP Access Request
2123
2124      The Request will succeed if it requires only rights
2125      granted to the requesting subject by the Update
2126      operation.  The Request will fail if it requires any
2127      right not granted by the Update operation.
2128
2129    - LDAP Update (Grant), Other, LDAP Access Request
2130
2131      The Request will succeed if it requires only rights
2132      granted to the requesting subject by the Update
2133      operation.  The Request may succeed if it requires
2134      rights not granted by the Update operation, depending
2135      on the policy in force before the Update operation.
2136
2137    - LDAP Update (Deny), Other, LDAP Access Request
2138
2139      The Request will fail if it requires any right denied
2140      to the requesting subject by the Update operation.  If
2141      the Request requires only rights which were not denied
2142      by the Update operation, it may succeed, depending on
2143      the policy in force before the Update operation.
2144
2145    - LDAP Update (Replace), Datastore Policy Update, LDAP
2146      Query
2147
2148      The result of the Query is not defined.
2149
2150    - LDAP Update (Grant), Datastore Policy Update, LDAP
2151      Query
2152
2153      The result of the Query is not defined.
2154
2155    - LDAP Update (Deny), Datastore Policy Update, LDAP Query
2156
2157      The result of the Query is not defined.
2158
2159    - LDAP Update (Replace), Datastore Policy Update, LDAP
2160      Access Request
2161
2162      The result of the Access Request is not defined.
2163
2164    - LDAP Update (Grant), Datastore Policy Update, LDAP
2165      Access Request
2166
2167      The result of the Access Request is not defined.
2168
2169    - LDAP Update (Deny), Datastore Policy Update, LDAP
2170      Access Request
2171
2172
2173
2174 Stokes, et al      Expires 14 January 2001         [Page 34]
2175 \f
2176
2177
2178
2179
2180 Internet-Draft      Access Control Model        14 July 2000
2181
2182
2183
2184      The result of the Access Request is not defined.
2185
2186
2187
2188 10.  Access Control Parameters for LDAP Controls & Extended
2189 Operations
2190
2191 This section defines the parameters used in the access
2192 control LDAP controls and extended operations in this
2193 document.
2194
2195 targetDN specifies the initial directory entry in DN syntax
2196 on which the control or extended operation is performed.
2197
2198 whichObject specifies whether the access control information
2199 (in the get effective rights control) which is retrieved is
2200 for the target directory entry (ENTRY) or the target
2201 directory entry and its subtree (SUBTREE).
2202
2203 rights in the get effective rights control or extended
2204 operation response is of the form specified in the BNF for
2205 <rights>.
2206
2207 subject is a LDAP string that defines the subject.  Access
2208 control is get/set on a subject.  The syntax of the subject
2209 is the same as the subject field in the BNF.
2210
2211
2212
2213 11.  Access Control Information (ACI) Controls
2214
2215 The access control information controls provide a way to
2216 manipulate access control information in conjunction with a
2217 LDAP operation.  One LDAP control is defined.  This control
2218 allows access control information to be retrieved while
2219 manipulating other directory information for that entry.
2220 The control is:
2221
2222    - getEffectiveRights to obtain the effective rights for a
2223      given directory entry(s) for a given subject during a
2224      ldap_search operation
2225
2226 11.1  getEffectiveRights Control
2227
2228
2229 11.1.1  Request Control
2230
2231 This control may only be included in the ldap_search
2232 message as  part of the controls  field  of the
2233 LDAPMessage, as  defined in  Section  4.1.12 of [LDAPv3].
2234
2235
2236
2237
2238 Stokes, et al      Expires 14 January 2001         [Page 35]
2239 \f
2240
2241
2242
2243
2244 Internet-Draft      Access Control Model        14 July 2000
2245
2246
2247
2248 The controlType is set to <OID to be assigned>. The
2249 criticality MAY be either TRUE or FALSE (where absent is
2250 also equivalent to FALSE) at the client's option.  The
2251 controlValue is an OCTET STRING, whose value is the BER
2252 encoding of a value of the following SEQUENCE:
2253
2254  getEffectiveRightsRequest ::= SEQUENCE {
2255    effectiveRightsRequest   SEQUENCE OF SEQUENCE {
2256        whichObject   ENUMERATED {
2257                      LDAP_ENTRY (1),
2258                      LDAP_SUBTREE (2)
2259                      },
2260        subject       <see <subject > in BNF> | "*"
2261        }
2262  }
2263
2264 The effectiveRightsRequest is a set of sequences that state
2265 the whichObject (entry or entry plus subtree) and specifics
2266 of the control request to be performed. A "*" in the subject
2267 field specifies that all DN types are to be used in
2268 returning the effective rights.  This control is applied to
2269 the filter and scope set by the ldap_search operation, i.e.
2270 base, one-level, subtree.  So the attributes/values returned
2271 are defined by the ldap_search operation.
2272
2273 11.1.2  Response Control
2274
2275 This control is included in the ldap_search_response message
2276 as part of the controls field of the LDAPMessage, as defined
2277 in Section 4.1.12 of [LDAPv3].
2278
2279 The controlType is set to <OID to be assigned>. There is no
2280 need to set the criticality on the response.  The
2281 controlValue is an OCTET STRING, whose value is the BER
2282 encoding of a value of the following SEQUENCE:
2283
2284  getEffectiveRightsResponse ::= {
2285    result  ENUMERATED {
2286       success                       (0),
2287       operationsError               (1),
2288       unavailableCriticalExtension (12),
2289       noSuchAttribute              (16),
2290       undefinedAttributeType       (17),
2291       invalidAttributeSyntax       (21),
2292       insufficientRights           (50),
2293       unavailable                  (52),
2294       unwillingToPerform           (53),
2295       other                        (80)
2296       }
2297  }
2298
2299
2300
2301
2302 Stokes, et al      Expires 14 January 2001         [Page 36]
2303 \f
2304
2305
2306
2307
2308 Internet-Draft      Access Control Model        14 July 2000
2309
2310
2311
2312 The effective rights returned are returned with each entry
2313 returned by the search result.  The control response for
2314 ldap_search is:
2315
2316  PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
2317     rights        <see <rights> in BNF>,
2318     whichObject   ENUMERATED {
2319                       LDAP_ENTRY (1),
2320                       LDAP_SUBTREE (2)
2321                       },
2322     subject       < see <subject> in BNF >
2323  }
2324
2325 Although this extends the search operation, there are no
2326 incompatibilities between versions.  LDAPv2 cannot send a
2327 control, hence the above structure cannot be returned to a
2328 LDAPv2 client.  A LDAPv3 client cannot send this request to
2329 a LDAPv2 server.  A LDAPv3 server not supporting this
2330 control cannot return the additional data.
2331
2332 11.1.3  Client-Server Interaction
2333
2334 The getEffectiveRightsRequest control requests the rights
2335 that MUST be in effect for requested directory
2336 entry/attribute based on the subject DN.  The server that
2337 consumes the search operation looks up the rights for the
2338 returned directory information based on the subject DN and
2339 returns that rights information.
2340
2341 There are six possible scenarios that may occur as a result
2342 of the getEffectiveRights control being included on the
2343 search request:
2344
2345
2346   1.  If the server does not support this control and the
2347       client specified TRUE for the control's criticality
2348       field, then the server MUST return
2349       unavailableCriticalExtension as a return code in the
2350       searchResponse message and not send back any other
2351       results.  This behavior is specified in section 4.1.12
2352       of [LDAPv3].
2353
2354   2.  If the server does not support this control and the
2355       client specified FALSE for the control's criticality
2356       field, then the server MUST ignore the control and
2357       process the request as if it were not present.  This
2358       behavior is specified in section 4.1.12 of [LDAPv3].
2359
2360   3.  If the server supports this control but for some
2361       reason such as cannot process specified family and the
2362       client specified TRUE for the control's criticality
2363
2364
2365
2366 Stokes, et al      Expires 14 January 2001         [Page 37]
2367 \f
2368
2369
2370
2371
2372 Internet-Draft      Access Control Model        14 July 2000
2373
2374
2375
2376       field, then the server SHOULD do the following: return
2377       unavailableCriticalExtension as a return code in the
2378       searchResult message.
2379
2380   4.  If the server supports this control but for some
2381       reason such as cannot process specified family and the
2382       client specified FALSE for the control's criticality
2383       field, then the server should process as 'no rights
2384       returned for that family' and include the result
2385       Unavailable in the getEffectiveRightsResponse control
2386       in the searchResult message.
2387
2388   5.  If the server supports this control and can return the
2389       rights per the family information, then it should
2390       include the getEffectiveRightsResponse control in the
2391       searchResult message with a result of success.
2392
2393   6.  If the search request failed for any other reason,
2394       then the server SHOULD omit the
2395       getEffectiveRightsResponse control from the
2396       searchResult message.
2397
2398 The client application is assured that the correct rights
2399 are returned for scope of the search operation if and only
2400 if the getEffectiveRightsResponse control returns the
2401 rights.  If the server omits the getEffectiveRightsResponse
2402 control from the searchResult message, the client SHOULD
2403 assume that the control was ignored by the server.
2404
2405 The getEffectiveRightsResponse control, if included by the
2406 server in the searchResponse message, should have the
2407 getEffectiveRightsResult set to either success if the rights
2408 are returned or set to the appropriate error code as to why
2409 the rights could not be returned.
2410
2411 The server may not be able to return a right because it may
2412 not exist in that directory object's attribute; in this
2413 case, the rights request is ignored with success.
2414
2415
2416 12.  Access Control Extended Operation
2417
2418 An extended operation, get effective rights, is defined to
2419 obtain the effective rights for a given directory entry for
2420 a given subject.  This operation may help with the
2421 management of access control information independent of
2422 manipulating other directory information.
2423
2424
2425
2426
2427
2428
2429
2430 Stokes, et al      Expires 14 January 2001         [Page 38]
2431 \f
2432
2433
2434
2435
2436 Internet-Draft      Access Control Model        14 July 2000
2437
2438
2439
2440 12.1  LDAP Get Effective Rights Operation
2441
2442 ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE
2443 {
2444    requestName      [0] <OID to be assigned>,
2445    requestValue     [1] OCTET STRING OPTIONAL }
2446
2447    where
2448
2449    requestValue ::= SEQUENCE {
2450       targetDN  LDAPDN,
2451       updates   SEQUENCE OF SEQUENCE {
2452                   whichObject   ENUMERATED {
2453                                   LDAP_ENTRY (1),
2454                                   LDAP_SUBTREE (2)
2455                                   },
2456                   attr SEQUENCE {
2457                      attr   <see <attr> in BNF >
2458                      },
2459                   subject   < see <subject> in BNF > | "*"
2460                   }
2461       }
2462
2463
2464 The requestName is a dotted-decimal representation of the
2465 OBJECT IDENTIFIER corresponding to the request. The
2466 requestValue is information in a form defined by that
2467 request, encapsulated inside an OCTET STRING.
2468
2469 The server will respond to this with an LDAPMessage
2470 containing the ExtendedResponse which is a rights list.
2471
2472 ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE
2473 {
2474    COMPONENTS OF LDAPResult,
2475    responseName     [10] <OID to be assigned> OPTIONAL,
2476    effectiveRights  [11] OCTET STRING OPTIONAL }
2477
2478    where
2479
2480    effectiveRights ::= SEQUENCE OF SEQUENCE {
2481       rights        <see <rights> in BNF>,
2482       whichObject   ENUMERATED {
2483                        LDAP_ENTRY (1),
2484                        LDAP_SUBTREE (2)
2485                        },
2486       subject       < see <subject> in BNF >
2487    }
2488
2489 If the server does not recognize the request name, it MUST
2490 return only the response fields from LDAPResult, containing
2491
2492
2493
2494 Stokes, et al      Expires 14 January 2001         [Page 39]
2495 \f
2496
2497
2498
2499
2500 Internet-Draft      Access Control Model        14 July 2000
2501
2502
2503
2504 the protocolError result code.
2505
2506
2507
2508 13.  Security Considerations
2509
2510 This document proposes protocol elements for transmission of
2511 security policy information.  Security considerations are
2512 discussed throughout this draft.  Because subject security
2513 attribute information is used to evaluate decision requests,
2514 it is security-sensitive information and must be protected
2515 against unauthorized modification whenever it is stored or
2516 transmitted.
2517
2518 Interaction of access control with other directory functions
2519 (other than the ones defined in this document) are not
2520 defined in this document, but instead in the documents where
2521 those directory functions are defined.  For example, the
2522 directory replication documents should address the
2523 interaction of access control with the replication function.
2524
2525
2526
2527 14.  References
2528
2529 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
2530 Access Protocol (v3)", RFC 2251, December 1997.
2531
2532 [ECMA] ECMA, "Security in Open Systems: A Security
2533 Framework" ECMA TR/46, July 1988.
2534
2535 [REQTS] Stokes, Byrne, Blakley, "Access Control Requirements
2536 for LDAP", RFC 2820, May 2000.
2537
2538 [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
2539 Directory Access Protocol (v3)": Attribute Syntax
2540 Definitions, RFC 2252, December 1997.
2541
2542 [UTF] M. Wahl, S. Kille, "Lightweight Directory Access
2543 Protocol (v3)": A UTF-8 String Representation of
2544 Distinguished Names", RFC 2253, December 1997.
2545
2546 [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
2547 Indicate Requirement Levels", RFC 2119.
2548
2549 [AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R.
2550 Morgan, "Authentication Methods for LDAP", RFC 2829, May
2551 2000.
2552
2553 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
2554 Specifications: ABNF", RFC 2234, November 1997.
2555
2556
2557
2558 Stokes, et al      Expires 14 January 2001         [Page 40]
2559 \f
2560
2561
2562
2563
2564 Internet-Draft      Access Control Model        14 July 2000
2565
2566
2567
2568 ACKNOWLEDGEMENT
2569
2570 This is to acknowledge the numerous companies and individuals who have
2571 contributed their valuable help and insights to the development of this
2572 specification.
2573
2574
2575 AUTHOR(S) ADDRESS
2576
2577  Ellen Stokes                       Bob Blakley
2578  Tivoli Systems                     Tivoli Systems
2579  6300 Bridgepoint Parkway           6300 Bridgepoint Parkway
2580  Austin, TX 78731                   Austin, TX 78731
2581  USA                                USA
2582  mail-to: estokes@tivoli.com        mail-to: blakley@tivoli.com
2583  phone: +1 512 436 9098             phone: +1 512 436 1564
2584  fax:   +1 512 436 1199             fax:   +1 512 436 1199
2585
2586
2587  Debbie Rinkevich                   Robert Byrne
2588  IBM                                Sun Microsystems
2589  11400 Burnet Rd                    29 Chemin du Vieux Chene
2590  Austin, TX 78758                   Meylan ZIRST 38240
2591  USA                                France
2592  mail-to: djbrink@us.ibm.com        mail-to: rbyrne@france.sun.com
2593  phone: +1 512 838 1960             phone: +33 (0)4 76 41 42 05
2594  fax:   +1 512 838 8597
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622 Stokes, et al      Expires 14 January 2001         [Page 41]
2623 \f
2624
2625
2626
2627
2628 Internet-Draft      Access Control Model        14 July 2000
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686 Stokes, et al      Expires 14 January 2001         [Page 42]
2687 \f
2688
2689
2690
2691
2692
2693
2694
2695
2696                           CONTENTS
2697
2698
2699  1.  Introduction.......................................   2
2700
2701  2.  The LDAPv3 Access Control Model....................   2
2702
2703  3.  Access Control Mechanism Attributes................   5
2704      3.1   Root DSE Attribute for Access Control
2705            Mechanism....................................   5
2706      3.2   Root DSE Attribute for Control of Disclosing
2707            Errors.......................................   5
2708      3.3   Subentry Class Access Control Mechanism......   6
2709
2710  4.  The Access Control Information Attribute
2711      (ldapACI)..........................................   7
2712      4.1   The BNF......................................   8
2713            4.1.1   ACI String Representation   8
2714            4.1.2   ACI Binary Representation  10
2715      4.2   The Components of ldapACI Attribute..........  11
2716            4.2.1   Scope  11
2717            4.2.2   Access Rights and Permissions  11
2718            4.2.3   Attributes  14
2719            4.2.4   Subjects and Associated
2720                    Authentication  15
2721      4.3   Grant/Deny Evaluation Rules..................  15
2722
2723  5.  Required Permissions for each LDAP Operation.......  17
2724      5.1   Bind Operation...............................  18
2725      5.2   Search Operation.............................  18
2726      5.3   Modify Operation.............................  21
2727      5.4   Add Operation................................  22
2728      5.5   Delete Operation.............................  23
2729      5.6   Modify DN Operation..........................  23
2730      5.7   Compare Operation............................  24
2731      5.8   Abandon Operation............................  25
2732      5.9   Extended Operation...........................  25
2733
2734  6.  Required Permissions for Handling Aliases and
2735      References.........................................  25
2736      6.1   ACI Distribution.............................  25
2737      6.2   Aliases......................................  26
2738      6.3   Referrals....................................  26
2739
2740  7.  Controlling Access to Access Control
2741      Information........................................  27
2742
2743  8.  ACI Examples.......................................  27
2744      8.1   Attribute Definition.........................  27
2745      8.2   Modifying the ldapACI Values.................  28
2746      8.3   Evaluation...................................  30
2747
2748
2749
2750                            - i -
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762  9.  Operational Semantics of Access Control
2763      Operations.........................................  31
2764      9.1   Types of actions.............................  32
2765      9.2   Semantics of Histories.......................  32
2766
2767 10.  Access Control Parameters for LDAP Controls &
2768      Extended Operations................................  35
2769
2770 11.  Access Control Information (ACI) Controls..........  35
2771      11.1  getEffectiveRights Control...................  35
2772            11.1.1  Request Control  35
2773            11.1.2  Response Control  36
2774            11.1.3  Client-Server Interaction  37
2775
2776 12.  Access Control Extended Operation..................  38
2777      12.1  LDAP Get Effective Rights Operation..........  39
2778
2779 13.  Security Considerations............................  40
2780
2781 14.  References.........................................  40
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816                            - ii -
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828 Full Copyright Statement
2829
2830 Copyright (C) The Internet Society (2000).á All Rights
2831 Reserved.
2832
2833 This document and translations of it may be copied and
2834 furnished to others, and derivative works that comment on or
2835 otherwise explain it or assist in its implementation may be
2836 prepared, copied, published and distributed, in whole or in
2837 part, without restriction of any kind, provided that the
2838 above copyright notice and this paragraph are included on
2839 all such copies and derivative works.á However, this
2840 document itself may not be modified in any way, such as by
2841 removing the copyright notice or references to the Internet
2842 Society or other Internet organizations, except as needed
2843 for the purpose of developing Internet standards in which
2844 case the procedures for copyrights defined in the Internet
2845 Standards process must be followed, or as required to
2846 translate it into languages other than English.
2847
2848 The limited permissions granted above are perpetual and will
2849 not be revoked by the Internet Society or its successors or
2850 assigns.
2851
2852 This document and the information contained herein is
2853 provided on an "AS IS" basis and THE INTERNET SOCIETY AND
2854 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
2855 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
2856 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
2857 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2858 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882                           - iii -
2883
2884
2885
2886