![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to design.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu|
Return to design.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu |
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.