Return to design.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu

Annotation of 43BSDReno/contrib/isode-beta/doc/quipu/design.tex, revision 1.1

1.1     ! root        1: 
        !             2: \chapter {General Design}
        !             3: 
        !             4: \section {Overview}
        !             5: 
        !             6: This chapter describes general decisions.  
        !             7: In particular, issues relating to use of
        !             8: the OSI Directory are covered,
        !             9: rather than
        !            10: system implementation decisions.
        !            11: However, the two are somewhat bound up.
        !            12: Attention is drawn to the protocol extensions defined in section
        !            13: \ref{edb-ros}.  Note that this does {\em not} affect interactions with
        !            14: non-QUIPU DSAs (or DUAs).
        !            15: The following aspects of the OSI Directory are not handled in QUIPU 5.0.
        !            16: 
        !            17: \begin {itemize}
        !            18: \item The protocol elements for support of directory use of authentication
        !            19: are handled in a conformant manner, but the associated services are not
        !            20: available to the end user.
        !            21: 
        !            22: \item
        !            23: Search is always supported by multicasting.  This does
        !            24: {\em not} affect the basic service offered to the user, but means that
        !            25: prohibition of chaining is not possible in all cases.  
        !            26: 
        !            27: \item For full subtree searches the filter is not applied to the base object.
        !            28: 
        !            29: \item Partial Outcome Qualifier is not supported for List.
        !            30: 
        !            31: \item There are some aspects of distributed operation, where interaction
        !            32: with another conforming system would not be fully general.  In particular,
        !            33: QUIPU might not be able to be configured with references to point at a
        !            34: complex configuration where not all sibling entries are held.  
        !            35: \end {itemize}
        !            36: 
        !            37: Otherwise, QUIPU 5.0 is believed to conform to the standard.
        !            38: 
        !            39: \section {Service Controls}
        !            40: 
        !            41: QUIPU use of service controls conforms to the OSI Directory.
        !            42: Comments are made on those
        !            43: controls where QUIPU makes a choice with respect to some option
        !            44: given by the OSI Directory.
        !            45: 
        !            46: \begin {description}
        !            47: \item [preferChaining]
        !            48: Chaining will be done.
        !            49: 
        !            50: \item [chainingProhibited]
        !            51: Chaining will not be done.
        !            52: For some cases of the search operation, this means that the QUIPU Directory
        !            53: Service will not be able to provide the service, and will return a
        !            54: ``chaining required'' error.
        !            55: 
        !            56: 
        !            57: \item [localScope]
        !            58: The scope will be restricted to the DSA concerned (i.e., no chaining will be
        !            59: done).
        !            60: 
        !            61: \item [dontUseCopy] If this is set, the master data will be used.  This may
        !            62: have a significant impact on performance for operations on entries which are
        !            63: high up the tree and for the DSAs which master this information.  These issues
        !            64: need study.
        !            65: 
        !            66: 
        !            67: \item [dontDereferenceAliases]
        !            68: Followed as per the OSI Directory.
        !            69: 
        !            70: \item [priority]
        !            71: This will be used to help control scheduling within the DSA, but is not done
        !            72: in QUIPU 5.0.
        !            73: 
        !            74: \item [timeLimit]
        !            75: Followed as per the OSI Directory.
        !            76: 
        !            77: \item [sizeLimit]
        !            78: Followed as per the OSI Directory.
        !            79: 
        !            80: \item [scopeOfReferral]
        !            81: The OSI Directory is followed, although QUIPU does not make use of this control.
        !            82: \end {description}
        !            83: 
        !            84: 
        !            85: 
        !            86: \section {Access Control}
        !            87: \label {acl-def}
        !            88: 
        !            89: The term Access Control is used to mean the control of user access
        !            90: to data.  Access Control relies on authentication, which is discussed
        !            91: separately.
        !            92: Although there is no Access Control defined in the standard, it is
        !            93: essential for any real system.  The QUIPU directory handles this by
        !            94: specifying an Access Control List (ACL) for each entry, which is stored as
        !            95: an attribute.  
        !            96: This mechanism allows for access control to be added without change
        !            97: of protocol.
        !            98: The ACL is defined in a manner which also
        !            99: allows specification of rights to update the ACL itself.  
        !           100: The Directory System knows about this attribute, and
        !           101: so can make choices based on it.  QUIPU Access Control is designed so that it is {\em
        !           102: not} required, and so will not prevent QUIPU interworking with other
        !           103: systems.  Non-QUIPU DUAs will not in general be able to specify or update
        !           104: QUIPU Access Control Lists,  as they will not support the special syntax.
        !           105: The syntax
        !           106: is given in Figure~\ref{acl-py}.
        !           107: 
        !           108: \tagrind {acl}{ACL definition}{acl-py}
        !           109: \clearpage
        !           110: 
        !           111: Access control is performed by a structure ACL, which is implemented as an
        !           112: attribute stored with each entry.  The ACL contains a number of elements
        !           113: called ACLInfo, which are applied to various objects.
        !           114: The ACLInfo is
        !           115: composed of two components: the AccessSelector and a list of Access
        !           116: Categories.
        !           117: The ACLSelector
        !           118: describes which DUAs are granted rights, and has four types:
        !           119: 
        !           120: \begin {itemize}
        !           121: \item
        !           122: The DUA corresponding to the entry.
        !           123: \item
        !           124: All DUAs (i.e., public access)
        !           125: \item
        !           126: Specific subtrees of the DIT - typically this will be a single DUA (i.e., a
        !           127: degenerate subtree).
        !           128: This can also be used to restrict information to within Organisations.
        !           129: \item
        !           130: Groups of DUAs.
        !           131: In this case, the entry specified must be of object class ``Organisational
        !           132: Role'' or ``Group of Names''.
        !           133: The DUAs with rights are identified by the ``Role Occupant'' and ``Member''
        !           134: attributes respectively.
        !           135: \end {itemize}
        !           136: 
        !           137: The AccessCategories can be applied to Attributes, Entries, and Children, in
        !           138: the manner described below.
        !           139: The values of access category are ordered, and a given level implies all
        !           140: previous rights.
        !           141: 
        !           142: \subsection {ACLInfo applied to Attributes}
        !           143: 
        !           144: This describes the semantics of each Access Category between the identified
        !           145: attribute and DUAs identified by the AccessSelector.
        !           146: 
        !           147: \begin {description}
        !           148: \item [none]
        !           149: 
        !           150: This prevents any knowledge of the attribute.
        !           151: \item [detect]
        !           152: 
        !           153: Detect if the attribute is present.
        !           154: \item [compare]
        !           155: Compare given value with all attribute values
        !           156: \item [read]
        !           157: Read all attribute values
        !           158: \item [add]
        !           159: As for read, and allows addition of new values.
        !           160: \item [write]
        !           161: As for add, and allows removal (and thus modification) of
        !           162: existing values.
        !           163: \end {description}
        !           164: 
        !           165: \subsection {ACLInfo applied to entries}
        !           166: 
        !           167: \begin {description}
        !           168: \item [none]
        !           169: 
        !           170: This prevents any knowledge of the entry.
        !           171: \item [detect]
        !           172: 
        !           173: This allows the existence of the entry to be determined.
        !           174: \item [compare]
        !           175: This allows the RDN to be compared.
        !           176: \item [read]
        !           177: This allows the RDN to be read.
        !           178: \item [add]
        !           179: This allows new attributes to be added.
        !           180: \item [write]
        !           181: This allows the RDN to be changed, and attributes to be
        !           182: deleted.
        !           183: \end {description}
        !           184: 
        !           185: \subsection {childACL}
        !           186: 
        !           187: This applies to the level 
        !           188: {\em immediately}
        !           189: below the entry in question.
        !           190: There is no implication for levels further down.
        !           191: 
        !           192: \begin {description}
        !           193: \item [none]
        !           194: The DUA is completely blocked from downwards progress.
        !           195: \item [detect]
        !           196: 
        !           197: This allows admission of the existence of lower layers  (e.g., a read
        !           198: would return securityError rather than name error).
        !           199: \item [compare]
        !           200: This allows exactly specified RDNs to be matched, but no more.
        !           201: \item [read]
        !           202: This allows child information to be listed, and for searching of the DIT
        !           203: below this entry.
        !           204: \item [add]
        !           205: This allows new children to be added.
        !           206: \item [write]
        !           207: Add access, and allows deletion of existing children.
        !           208: \end {description}
        !           209: 
        !           210: The add access category is subtly different when applied to the (single valued)
        !           211: ACL attribute.
        !           212: A DUA which has add access to the ACL may modify the ACL Attribute 
        !           213: extend access to any
        !           214: attribute.
        !           215: It may not give more access rights to any attribute or default than the DUA
        !           216: itself has (i.e., if you have write access to an attribute, you can
        !           217: permit someone else to have write access to it {\em if} you have add access to
        !           218: the ACL).
        !           219: 
        !           220: \subsection {Example Use of ACLs}
        !           221: 
        !           222: An example of how this structure might be used is given.
        !           223: An organisation might give a leaf attribute the following values:
        !           224: 
        !           225: \begin {itemize}
        !           226: \item
        !           227: ChildACL is not applicable, and so omitted.
        !           228: \item
        !           229: EntryACL is \{other, read\} + \{group = DSA Managers, write\}, which
        !           230: restricts addition of new attributes to managers.
        !           231: \item
        !           232: DefaultAttributeACL is \{other, read\} + \{self, write\}, which leads to
        !           233: publicly readable attributes modifyable by the owner.
        !           234: \item
        !           235: Common Name is
        !           236: \{other, read\} + \{group = DSA Managers, write\}, which restricts name
        !           237: changes to the manager.
        !           238: \item
        !           239: ACL is \{self, add\} + \{group = DSA Managers, write\}, which allows the
        !           240: user to grant access, but not to reduce it.
        !           241: \item
        !           242: Password is \{self, write\} + \{group = DSA Managers, write\}
        !           243: \end {itemize}
        !           244: 
        !           245: It can be seen that this scheme gives a great deal of flexibility,
        !           246: without the addition of any protocol elements.
        !           247: The encoding is designed so that the volume overhead is not excessive
        !           248: for sensible access policies.
        !           249: 
        !           250: \subsection {An issue for further study}
        !           251: 
        !           252: One serious problem not tackled is that of allowing limited access, where
        !           253: some level of matching is allowed, but exhaustive listing by repeated query
        !           254: is made prohibitively expensive.  No satisfactory solution has been devised,
        !           255: and so this problem is being left for further study.
        !           256: 
        !           257: 
        !           258: 
        !           259: \section {Authentication}
        !           260: 
        !           261: QUIPU takes a minimal approach to authentication.
        !           262: Simple Authentication is seen as a minimum, which is straightforward to
        !           263: implement.
        !           264: The Password attribute is used.
        !           265: 
        !           266: Simple Authentication is used between DUA and DSA.
        !           267: Simple authentication will be used between DSAs in QUIPU 6.0\footnote{It is
        !           268: not used in QUIPU 5.0, because the performance degradation has proven to be
        !           269: too high prior to the introduction of on-disk caching as described in
        !           270: Section~\ref{disk-cache}.}.
        !           271: This is felt to be the minimum level acceptable for some aspects of
        !           272: the planned usage (e.g., user modification of data).
        !           273: Other uses of QUIPU will not require authentication (e.g., lookup of
        !           274: some OSI information).
        !           275: DSAs authenticate each other to provide the basis
        !           276: for mutual trust.  
        !           277: The first DSA will authenticate the DUA on the basis of password plus
        !           278: DUA name in the A\_Associate, as described in the OSI Directory.
        !           279: Subsequent DSAs will trust the DUA parameter given in the DSP (i.e.
        !           280: there is mutual trust between QUIPU DSAs, with DSAs performing mutual
        !           281: authentication).
        !           282: Looping (livelock) is possible, as each DSA must use the directory to
        !           283: perform authentication.   
        !           284: This will be prevented by the DSA naming procedures described in the
        !           285: Section~\ref{dsa-naming} on page \pageref{dsa-naming}, as well as by use of
        !           286: DSA Trace.
        !           287: 
        !           288: \section {Schemas}
        !           289: 
        !           290: Directories should provide a very flexible tool
        !           291: which enables any information to be stored.  There is a danger that Schemas,
        !           292: as specified in the OSI Directory, will lead to procrustean directory implementations
        !           293: which impose unreasonable restrictions.  The QUIPU Directory will not, per
        !           294: se, place restrictions on what can be placed in a DSA.
        !           295: It will give control so that managers may control what is stored in the
        !           296: directory.
        !           297: 
        !           298: \subsection {Matching}
        !           299: 
        !           300: There is a need to understand Attribute Syntaxes in order to perform correct
        !           301: matching.
        !           302: The QUIPU DSA ``knows'' about a limited number of standard
        !           303: syntaxes, and some  special ones defined in this document.
        !           304: These receive an optimised internal encoding, and special (typically
        !           305: faster) matching.
        !           306: Any other structures are mapped to one of the known syntaxes (if the ASN.1 is
        !           307: unambiguous --- e.g. ``PrintableString'' is unambiguous, whereas ``[0] IMPLICIT
        !           308: PrintableString'' is not), or treated as generic ASN.1.
        !           309: 
        !           310: The supported standard syntaxes are:
        !           311: 
        !           312: \begin {enumerate}
        !           313: \item Case Exact String.
        !           314: \item Case Ignore String.
        !           315: \item Numeric String.
        !           316: \item Distinguished Name.
        !           317: \item Boolean
        !           318: \item Integer
        !           319: \item UTC Time
        !           320: \item Object Identifier
        !           321: \item Presentation Address. 
        !           322: \end {enumerate}
        !           323: 
        !           324: Other supported syntaxes are: 
        !           325: 
        !           326: \begin {enumerate}
        !           327: \item ASN.1.  This is a general catch-all, and will deal with most syntaxes
        !           328: which do not have ``special'' rules (see below).
        !           329: \item Object Class (some special QUIPU handling)
        !           330: \item QUIPU ACL
        !           331: \item QUIPU Schema (Tree Structure).
        !           332: \item QUIPU Update Control.
        !           333: \item Photographs encoded in G3 Fax
        !           334: \end {enumerate}
        !           335: 
        !           336: Generic attributes stored as ASN.1, will usually be matched correctly, with
        !           337: the following exceptions:
        !           338: 
        !           339: \begin {itemize}
        !           340: \item
        !           341: There is an IMPLICIT Set in the ASN.1.  The DSA will not detect the
        !           342: set, and so will not know to match components in arbitrary order.
        !           343: 
        !           344: \item
        !           345: If special matching rules apply: for example, special rules to
        !           346: determine equivalence of telephone numbers.  Such rules would need
        !           347: to be represented by code in the DSA.
        !           348: \end {itemize}
        !           349: 
        !           350: \subsection {Structure}
        !           351: 
        !           352: The first aspect of structure is with respect to attributes which may be
        !           353: present in an entry.  A QUIPU DSA will allow an entry to belong to one or
        !           354: more object classes which are known to the DSA (stored in a table).  An
        !           355: entry will typically have a small number of object classes (e.g., TOP
        !           356: (implicit) + Person + Organisational Person + QUIPU Object).  The DSA will
        !           357: maintain a table of mandatory and optional attributes for each object class
        !           358: supported.  This will be follow the guidelines of the standard or
        !           359: specification identifying the object class in question.  From this
        !           360: information, the DSA can determine the permitted and mandatory attributes for a
        !           361: given entry, by calculating the union of all the object classes of that
        !           362: entry.  Free extension (i.e., the ability to store any attribute) was
        !           363: rejected, as there does not appear to be a reasonable mechanism to manage
        !           364: this.  However, it is straightforward for managers to create new object
        !           365: classes as desired.
        !           366: 
        !           367: It is important 
        !           368: to allow management control of what is permitted at a given level.
        !           369: Therefore a ``tree structure''
        !           370: attribute may be created.  
        !           371: This attribute is defined in Figure~\ref{schema-py}.
        !           372: This specifies for the level below,
        !           373: what types of object are permitted.  
        !           374: Each attribute value identifies a class of object which can exist at the level
        !           375: below, and 
        !           376: defines a set of mandatory and optional object classes.
        !           377: This can be considered as defining a (private) object class implied by the
        !           378: combination of these classes.
        !           379: For each type of object, the attribute types permitted in the RDN are also
        !           380: listed.  This is not checked in QUIPU 5.0.
        !           381: The directory knows about the tree structure attribute, and will
        !           382: ensure consistency.  
        !           383: When creating an entry, the DSA must check that it conforms to the
        !           384: treeStructure attribute of the parent entry.
        !           385: When removing information from a treeStructure attribute, the
        !           386: Directory will  check that all of the children conform to the
        !           387: modified attribute.
        !           388: There may be some synchronisation problems in this area, if the tree
        !           389: structure was being modified at the same time as other data was added.
        !           390: However, this is a pathological case, and ignored by QUIPU at runtime.
        !           391: Management tools will be able to detect inconsistency at a later point.
        !           392: 
        !           393: 
        !           394: \tagrind[htb]{schema}{Schema definition}{schema-py}
        !           395: 
        !           396: 
        !           397: It is important to provide a mechanism whereby a user can examine the
        !           398: type structure of the  DIT.
        !           399: This is also achieved by the same mechanism.
        !           400: As well as giving the manager control, it allows the user to
        !           401: determine the (potential) shape of the tree, by reading and
        !           402: displaying the TreeStructure attribute.
        !           403: This can be used as a complement to the standard Search Guide attribute, 
        !           404: which indicates how searches in that region of the DIT are keyed.
        !           405: 
        !           406: \section {Extended Searching}
        !           407: 
        !           408: Phonetic searching is supported for all string based attributes.
        !           409: This will is done by holding a short array of soundex keys for each
        !           410: attribute value.
        !           411: The soundex keys are generated by the DSA at loadtime.
        !           412: Typically, there is  one soundex key for each component of a name.
        !           413: 
        !           414: 
        !           415: There is a problem with some attributes which can be looked at in a general
        !           416: or specific manner (e.g. phone number / home phone number).  This may be
        !           417: tackled in the standards bodies by introduction of Attribute Classes.
        !           418: We propose to investigate this area, prior to 1992.  Attribute Subclasses
        !           419: and Attribute Aliases will be
        !           420: defined {\em internally} to a QUIPU DSA.  Externally, all attributes will be
        !           421: shown, even where this means sending both subclass and superclass.
        !           422: Care must be taken on modifications, as all members of a superclass do not
        !           423: have to be members of the subclass.
        !           424: 
        !           425: There is a serious problem in handling personal names, and some other
        !           426: attributes.  It is intended to handle this as a generalisation of the
        !           427: attribute class mechanism.  Initially, this will be hard coded in as a
        !           428: special case for human names.  A name is considered to be represented as 
        !           429: either a string encoded common name, or a series of other attributes
        !           430: (Surname, Given Name, Initials, Title).  This can be viewed as a structured
        !           431: and unstructured representation of the same information.  These should be
        !           432: modified to be aligned.  All components of the structured form should be
        !           433: represented in the unstructured form, and vice versa.  In addition, any
        !           434: ``preferred form'' should be represented in the common name.  Initially, it
        !           435: will be mandatory for update to be via the structured form.
        !           436: 
        !           437: The details of this section will be expanded, and additions made to the naming
        !           438: architecture.
        !           439: 
        !           440: \section {Update}
        !           441: 
        !           442: Update is achieved by the operations specified in the OSI Directory.
        !           443: This gives fully general update on the basis of three considerations:
        !           444: 
        !           445: \begin {itemize}
        !           446: \item
        !           447: Access Control is specified by an attribute.
        !           448: Thus sophisticated control of remote update can be made.
        !           449: \item
        !           450: Because of the master/slave concept, updates can work in a distributed
        !           451: environment, where multiple DSAs are affected.
        !           452: This is described in Chapter~\ref{dist-update}.
        !           453: \item 
        !           454: Within the OSI Directory, the update operations give no indication as to the DSA
        !           455: where an entry should be added.
        !           456: In QUIPU, the 
        !           457: configuration of the Directory is represented in the Directory, and so
        !           458: updates can be made in the ``correct'' DSA(s).  
        !           459: \end {itemize}
        !           460: 
        !           461: 
        !           462: 
        !           463: 
        !           464: \section {Operation Status}
        !           465: 
        !           466: Some operations will take a long time.  Real implementations also hang up,
        !           467: and block.  It is useful for the user to determine how an operation is
        !           468: progressing.  It is proposed to add a QUIPU specific operation to the DAP,
        !           469: which allows a user to query how a given operation is progressing.  
        !           470: This might be done by a DUA invoked operation, or by a DSA invoked linked
        !           471: operation, which returns status at DUA specified intervals.
        !           472: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.