home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-acap-authid-00.txt < prev    next >
Text File  |  1997-07-24  |  16KB  |  477 lines
  1.  
  2. INTERNET DRAFT                                   Expires: December, 1997
  3. ACAP Working Group                                               S. Hole
  4. Internet Draft: ACAP                                The Esys Corporation
  5. Document: draft-ietf-acap-authid-00.txt                        July 1997
  6.  
  7.  
  8.                  ACAP Authorization Identifier Datasets
  9.  
  10.  
  11. Status of this memo
  12.  
  13.      This document is an Internet Draft.  Internet Drafts are working
  14.      documents of the Internet Engineering Task Force (IETF), its Areas,
  15.      and its Working Groups.  Note that other groups may also distribute
  16.      working documents as Internet Drafts.
  17.  
  18.      Internet Drafts are draft documents valid for a maximum of six
  19.      months.  Internet Drafts may be updated, replaced, or obsoleted by
  20.      other documents at any time.  It is not appropriate to use Internet
  21.      Drafts as reference material or to cite them other than as a
  22.      ``working draft'' or ``work in progress``.
  23.  
  24.      To learn the current status of any Internet-Draft, please check the
  25.      1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  26.      Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
  27.      munnari.oz.au.
  28.  
  29.      Discussion and suggestions for improvement are requested.  This
  30.      document will expire six months after publication.  Distribution of
  31.      this draft is unlimited.
  32.  
  33.  
  34. 0. Administrivia
  35.  
  36. 0.1.  Changes from Last Internet Draft
  37.  
  38. 0.2.  Open Issues
  39.  
  40. 1)   The definitions for authentication id's and tying authids to
  41.      userids is somewhat problematic.   Should we have specific authid
  42.      types (Kerberos principals, usernames, etc.) expressed as
  43.      individual attributes, or is a single multivalued attribute enough.
  44.  
  45.  
  46. 2)   We may want to consider a more structured namespace for the userid
  47.      and groupid datasets.   A per-application space below the top level
  48.      dataset could be used to do explicit per-application "account"
  49.      management.
  50.  
  51.  
  52.  
  53. Hole                                                            [Page 1]
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Internet Draft       ACAP Authorization Identifiers            July 1997
  60.  
  61.  
  62.      As defined right now, the application is expected to retain
  63.      "account" information in it's private space.   That is, the
  64.      assignment of what userid has access to things on a particular
  65.      server is private server data - perhaps held in ACAP, but perhaps
  66.      not.
  67.  
  68.  
  69. 3)   What language to use for an ACAP server that has the /userid and
  70.      /groupid datasets and (MAY, SHOULD, MUST) use that information
  71.      itself?
  72.  
  73.  
  74. 4)   There is potential for a number of other optional userid and
  75.      groupid attributes.  Examples are:
  76.            - disabled flag
  77.            - expiration date
  78.  
  79.  
  80. 1. Introduction
  81.  
  82.      Most distributed (client/server) applications require an
  83.      authentication process between the client and the server before the
  84.      server will grant access to its managed resources.  Many
  85.      applications provide varying levels of access to server resources
  86.      based on a combination of authentication credentials and access
  87.      control rules.   The collection of information used to control
  88.      access to resources is called "authorization information".
  89.  
  90.      The ACAP authentication identifier datasets offers a more powerful,
  91.      secure, and user friendly representation for authorization
  92.      information than simple authentication identifiers in distributed
  93.      applications.  The authorization identifer datasets contain lists
  94.      of users and groups of users that can be used by applications for
  95.      authorization purposes.  Access control mechanisms can be
  96.      abstracted from underlying authentication mechanisms and credential
  97.      formats.  They can be extended to include group memberships in
  98.      calculations for access rights to resources.
  99.  
  100.      The Application Configuration Access Protocol (ACAP) supports the
  101.      remote storage and access of many types of structured configuration
  102.      information.  The authorization identifier datasets specification
  103.      describes the "userid" and "groupid" datasets which contain the
  104.      authorization information.  It also describes ACAP server
  105.      capabilities that advertise a server's support for authorization
  106.      user and group semantics.
  107.  
  108.  
  109. 2. Conventions used in this document
  110.  
  111.  
  112.  
  113. Hole                                                            [Page 2]
  114.  
  115.  
  116.  
  117.  
  118.  
  119. Internet Draft       ACAP Authorization Identifiers            July 1997
  120.  
  121.  
  122.      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  123.      in this document are to be interpreted as described in [].
  124.  
  125.      The attribute syntax specifications use the Augmented Backus-Naur
  126.      Form (ABNF) notation as specified in [IMAIL].
  127.  
  128.  
  129. 3. Authorization user identifiers
  130.  
  131.      An ACAP "userid" (user identifier) is an abstraction for an
  132.      individual user that accesses server resources -- an authorization
  133.      user.  Typically, this a person acting as themselves, a person
  134.      acting in a role, or an application process.  Access rights to
  135.      server resources can be granted or denied to a userid.
  136.  
  137.      Authentication information is tied to a userid by an authentication
  138.      mechanism specific "authid" (authentication identifier).  More than
  139.      one authid can be associated with a single userid.
  140.  
  141.      Userids can be listed and displayed by a client without giving away
  142.      critical information on authentication information -- specifically
  143.      lists of authids.   Using ACAP access control lists, the authids
  144.      tied to a userid MAY be searched by a client but SHOULD NOT be
  145.      retrievable by a client.
  146.  
  147.  
  148. 3.1. ACAP userid dataset class
  149.  
  150.      Datasets whose names begin with "/userid" contain "userid" entries
  151.      as defined in this specification.  If present, an ACAP server
  152.      SHOULD calculate access rights for its own information resources
  153.      using the authorization information in this dataset.
  154.  
  155.  
  156. 3.2. Userid entry attributes
  157.  
  158.      A "userid" entry defines an authorization user for an application.
  159.      It is used by the application to grant or deny access to
  160.      application resources.  An application supporting ACAP "USER"
  161.      authorization semantics (as defined in section 5.) binds userids to
  162.      its resource access control rules.  Resource access rights are
  163.      calculated by applying, in an application specific way, the access
  164.      control rules that are bound to the current user's userid.
  165.  
  166.  
  167. 3.2.1.  Mandatory userid attributes
  168.  
  169.  
  170.  
  171.  
  172.  
  173. Hole                                                            [Page 3]
  174.  
  175.  
  176.  
  177.  
  178.  
  179. Internet Draft       ACAP Authorization Identifiers            July 1997
  180.  
  181.  
  182. entry
  183.  
  184.      The "entry" attribute MUST be defined for a userid entry.  It's
  185.      value is used by applications to calculate access rights to server
  186.      resources.  This SHOULD include the ACAP server itself.
  187.  
  188.  
  189. user.authid
  190.  
  191.      The "user.authid" attribute MUST be defined for userid entry.  It
  192.      MAY be multivalued.  It contains a list of authentication mechanism
  193.      specific authentication identifiers that bind to this userid.
  194.  
  195.  
  196. 3.2.2.  Optional userid attributes
  197.  
  198.  
  199. user.name
  200.  
  201.      The "user.name" attribute MAY be defined for a userid entry.  It
  202.      contains a name string which is suitable for presentation by an
  203.      ACAP client.  If present in a userid entry, clients SHOULD present
  204.      this value to the user rather than the value of the "entry"
  205.      attribute.  It is assumed to contain a more descriptive label for
  206.      the user than the userid itself, eg. the user's full name.
  207.  
  208.  
  209. user.description
  210.  
  211.      The "user.description" attribute MAY de defined for a userid entry.
  212.      It MUST be single valued.   The value contains text that describes
  213.      the user.
  214.  
  215.  
  216. user.memberof
  217.  
  218.      The "user.memberof" attribute MUST be defined for an entry if the
  219.      server supports the ACAP "GROUP" authorization semantics.  The
  220.      value of the attribute is the list of groupids that the userid is a
  221.      member of.  It is provided as a optimization convenience to the
  222.      client in the presence of group authorization semantics as defined
  223.      in section 5.  The value is readonly and MUST be calculated by the
  224.      server.
  225.  
  226.  
  227. 4. Authorization group identifiers
  228.  
  229.      An ACAP "groupid" (group identifier) is an abstraction for a set of
  230.  
  231.  
  232.  
  233. Hole                                                            [Page 4]
  234.  
  235.  
  236.  
  237.  
  238.  
  239. Internet Draft       ACAP Authorization Identifiers            July 1997
  240.  
  241.  
  242.      users that access server resources -- an authorization group.  A
  243.      groupid entry contains a list of userids that are members of the
  244.      group.  Access rights to server resources can be granted or denied
  245.      to a groupid.
  246.  
  247.  
  248.  
  249. 4.1. ACAP groupid dataset class
  250.  
  251.      Datasets whose names begin with "/groupid" are assumed to contain
  252.      groupid entries as defined in this specification.  If present, an
  253.      ACAP server SHOULD support group authorization semantics defined in
  254.      section 5.
  255.  
  256.  
  257. 4.2. Groupid entry attributes
  258.  
  259.      A "groupid" entry defines an authorization group for an
  260.      application.  It is used by an application to grant or deny access
  261.      to application resources.  An application supporting ACAP "GROUP"
  262.      authorization semantics (as defined in section 5.) binds groupids
  263.      to its resource access control rules.  Resource access rights are
  264.      calculated by applying, in an application specific way, the access
  265.      control rules that are bound to the groupids that the current
  266.      user's userid is a member of.
  267.  
  268.  
  269. 4.2.1.  Mandatory groupid attributes
  270.  
  271.  
  272. entry The "entry" attribute MUST be defined for a groupid entry.  Its
  273.      value is used by applications to calculate access rights to server
  274.      resources.  This SHOULD include the ACAP server itself.
  275.  
  276.  
  277. group.members.userid
  278.  
  279.      The "group.members.userid" attribute MUST be defined for a groupid
  280.      entry.  It MAY be multivalued.  The value of the attribute is an
  281.      unordered list of userids that are members of the authorization
  282.      group.
  283.  
  284.  
  285. group.members.groupid
  286.  
  287.      The "group.members.groupid" attribute MUST be defined for a groupid
  288.      entry.  It MAY be multivalued.  The value of the attribute is an
  289.      unordered list of groupids that are members of the authorization
  290.  
  291.  
  292.  
  293. Hole                                                            [Page 5]
  294.  
  295.  
  296.  
  297.  
  298.  
  299. Internet Draft       ACAP Authorization Identifiers            July 1997
  300.  
  301.  
  302.      group.
  303.  
  304.  
  305.  
  306. 4.2.2.  Optional groupid attributes
  307.  
  308.  
  309. group.name
  310.  
  311.      The "group.name" attribute MAY be defined for a groupid entry.  It
  312.      contains a name string which is suitable for presentation by an
  313.      ACAP client.  If present in a groupid entry, clients SHOULD present
  314.      this value to the user rather than the value of the "entry"
  315.      attribute.  It is assumed to contain a more descriptive label for
  316.      the group than the groupid itself, eg. the group's organizational
  317.      title.
  318.  
  319.  
  320. group.description
  321.  
  322.      The "group.description" attribute MAY be defined for a groupid
  323.      entry.  It MUST be single valued.   The value contains text that
  324.      describes the group.
  325.  
  326.  
  327.  
  328. 5. ACAP authorization
  329.  
  330.      The ACAP authorization information can be used by any application,
  331.      including the ACAP server itself.  The following sections describe
  332.      the use of the authorization identifier datasets by an ACAP
  333.      application (client or server) itself.
  334.  
  335.      Other applications are assumed to provide their own definitions for
  336.      use of ACAP authorization information.  Specifically, they are
  337.      expected to define how they notify clients that their access
  338.      control mechanisms make use of ACAP authorization information
  339.      datasets.
  340.  
  341.  
  342. 5.1. Userid access semantics
  343.  
  344.      If an ACAP server supports the "/userid" dataset, then it SHOULD
  345.      use the authorization information provided by it for access control
  346.      purposes.  After successful authentication to the ACAP server, an
  347.      authorization userid should be selected as the "current user" for
  348.      the ACAP server, either using the authid mapping information in the
  349.      userid entries, or using explicit userid information supported by
  350.  
  351.  
  352.  
  353. Hole                                                            [Page 6]
  354.  
  355.  
  356.  
  357.  
  358.  
  359. Internet Draft       ACAP Authorization Identifiers            July 1997
  360.  
  361.  
  362.      the authentication mechanism.  ACAP ACL's are based on userids
  363.      rather than authids.  Resource access rights are calculated
  364.      relative to the current userid.
  365.  
  366.  
  367. 5.1.1. ACAP "USER" capability
  368.  
  369.      If an ACAP server supports the "/userid" dataset and userid
  370.      authorization semantics, then it MUST express the "USER" capability
  371.      in an ACAP capability response.   The "USER" capability informs an
  372.      ACAP client that it MUST use the "/userid" dataset contents for any
  373.      ACL management on the server.   If a server does not express the
  374.      "USER" capability, then the client will assume that the server uses
  375.      authid information in ACL's.
  376.  
  377.  
  378. 5.2. Group access semantics
  379.  
  380.      If an ACAP server supports the "/groupid" dataset, then it SHOULD
  381.      use the authentication information in it.  ACAP ACL's can include
  382.      groupids in the ACL.  Resource access rights are calculated
  383.      relative to the current userid, and all groups that the current
  384.      userid is a member of.
  385.  
  386.  
  387. 5.2.1. ACAP "GROUP" capability
  388.  
  389.      If an ACAP server supports the "/groupid" dataset and userid
  390.      authorization semantics, then it MUST express the "GROUP"
  391.      capability in an ACAP capability response.   The "GROUP" capability
  392.      informs an ACAP client that it MUST use the "/groupid" dataset
  393.      contents for any ACL management on the server.   If a server does
  394.      not express the "GROUP" capability, then the client will assume
  395.      that the server does not support group semantics, and should not
  396.      present group information in ACAP ACL management functions.
  397.  
  398.  
  399. 6. References
  400.  
  401.      [ACAP] Newman, C., Myers, J. G., "Application Configuration Access
  402.      Protocol", Work in progress, July 1997.
  403.  
  404.          <ftp://ietf.org/internet-drafts/draft-ietf-acap-spec-04.txt>
  405.  
  406.  
  407.  
  408. 7. Security Considerations
  409.  
  410.  
  411.  
  412.  
  413. Hole                                                            [Page 7]
  414.  
  415.  
  416.  
  417.  
  418.  
  419. Internet Draft       ACAP Authorization Identifiers            July 1997
  420.  
  421.  
  422.      This specification defines a protocol for storing, accessing and
  423.      managing application resource authorization information.  It is
  424.      expected that this information will be used to grant and/or deny
  425.      access to users and groups for server based resources.
  426.  
  427.      ACAP server access controls should be set correctly on userid entry
  428.      attributes.  Clients SHOULD be able to search for userid entries
  429.      based on authentication identifier attributes, but SHOULD NOT be
  430.      able to retrieve any authentication identifier information.
  431.  
  432.      This specification does not define any kind of process, mechanism
  433.      or protocol for authentication in distributed network applications.
  434.      Use of the data and protocol elements described in this
  435.      specification are to be used after successful authentication
  436.      between the client and server.
  437.  
  438.      This specification does not discuss storage of any kind of
  439.      authentication credentials, in the form of private keys, shared
  440.      secrets or passwords in userid entries.   The information in the
  441.      authid dataset is intended purely for authorization and access
  442.      control purposes.
  443.  
  444.  
  445. 8. Authors' Addresses
  446.  
  447. Steve Hole
  448. The Esys Corporation
  449. 900 10040 - 104 St.
  450. Edmonton, Alberta, T5J 0Z2, CANADA
  451.  
  452. Email: Steve.Hole@esys.ca
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473. Hole                                                            [Page 8]
  474.  
  475.  
  476.  
  477.