CLI ENT CLIENT CLIENT
NATIVE NATIVE NATIVE
DIR ECTORY DIRECTORY D I RECTORY
SERVER S E R V E R S E R V E R
Figure 1
Structure of the I ntegrated Directory Services
e n try; it is a directory service object that represents some network object. A resource class is the defi nition of that type of d irectory entry. For example, the direc tory entr y that describes a specific printer is an I DS resource, and the I DS class that describes every printer entry is a resource class.
The framework provides extensibility by defining
C++ object classes that allow for the creation and
manipulation of resources, attributes, and attribute val ues i n a type- independent manner. The type inde pendence al lows both appl ications and the ti·amework itself to manipulate I D S attributes and attribute values without knowing their types. As long as the new types are built on top of existing I DS system types, applica tion writers may ddine new IDS types without mod i fYi n g the service providers.
The fi·amework d ispatches d irectory operations to the appropriate service provider and maintains overall system state and integrity. Tt maintains a l ist of the service providers that are currently available a nd shows the errors encountered in any fai led loads. This allows the svstem to continue to operate, albeit in a degraded st
�
te, even though one of the service providers may be malfunctioning.Before we d iscuss the design of the SPI, we describe tl1e framework's objects.
IDS Entry The fundamental IDS object is the canon i c a l representation o f a d irectory entry, t h e IDS en try.
Digiral Tc-dmical
Jounul
Vol .
8No.
I 1996The I DS entry is a n abstract object. To create a resource cl ass, applications define a resource type and derive it from the IDS entry. IDS entry objects are cre ated and manipul ated through the API and translated into the appropriate native directory format by the ser vice providers. Derivatives of the IDS entry may define J.d d i tional methods, but they may not override the I DS entr y methods. The IDS entry methods are part of the framework.
The I DS entry methods tall i n to one of two otegories: those wh.ich manipulate the attributes and values contai ned in the I DS entry in a type-indepen dent manner, a nd those which perform operations on the directorv. Each I D S entry, each attribute, and each attri bute val
�
1 e contains a type. For convenience, deriv atives of the I DS entry may define additional methods that manipulate certain attributes or values di rectly. For example, a derivation tl1at defines a printer might define a method to set rhe description attribute. The implementation of this method would cal l the general I DS entry attri bute and value manipu lation method to set the value of the appropriate attribute.As shown i n Figure 2, the IDS entry contains identi f),ing information and the attributes and attribute val ues that describe the resource. The context identi fies the service provider that performs directory opera tions on this entry and the location within that directory service in vvhich this entry is stored . The resource type detines the kind of resource that this entry represents. The resource name is the name by which applications and users refer to the entry.
The attributes of the entry are contained in a set. Each attri bute in turn contains the vJiue or list of val ues associated witll the attribute.
Contexts The context is an object that uniquely iden
tif-ies a particular location in a particular namespace . The IDS context i s very similar i n concept to the XFl'i context." All contexts contain the type i de ntifier for the directory service and an internal name. The type identi fier is used by the fDS framework to dispatch operations to the appropriate service provider. The internal name is the location within the directory ser vice described by this conrexr. The internal name is represented in the native syntax of the underlying di rectory service. The service provider is responsible tor setting and maintaining this internal name. ( See Figure 2 . )
Attributes and Attribute Val ues The type of an ::mribute defines the data type of its va lue or values. The attribute value object is a canonical representation of an acmal attri bute value. The attribute val ue object de f-ines a set of methods tor accessi ng and manipu lat ing val ues. For each data type supported in IDS, there is a corresponding attribute value derivation in the
RESOURCE TYPE IDS_PRINTER
CONTEXT SERVICE PROV I DER TYPE: LDAP LOCATION WITHIN SP: o=dec;ou=lkg
RESOURCE NAME NIST GROUP PRINTER
ATTRIBUTE SET ATTRI BUTE N
ATTRIBUTE 2
ATTRIBUTE 1
ATTRI BUTE TYPE IDS-ATTR-MAINTAINER
ATTRIBUTE VALUE LIST
ATTRIBUTE VALUE DATA TYPE -STRING E ATTR IBUTE VALUE JANE DO
ATTR IBUTE VALUE DATA TYPE ATTR I BUTE VALUE
ATTR IBUTE VALUE DATA TYPE
Figure 2
IDS
Entry
ATTRIBUTE VALUE
IDS framework . This allows applications, and the I DS framework itself, to manipulate attribute values with out knowing their types. The service providers, on the other hand , use the type information ro translate from the I DS data formats to their native data tonnats . Types To allow customers and third parties to identi�' their own IDS resources, the I DS type mechanism must uniquely identi�' objects. The two identifiers we considered using were universJI unique identifiers (UU IDs) as defined by the Open Sofuvare Foundation D istributed Computing Environment ( OSF DCE) and object identi tlers ( OIDs) JS defi ned by the open sys tems i nterconnection ( OS I ) standards. " · ' 2 Some direc tory services identity attributes with OIOs, whi le others use UUIDs. For appl ications defin ing new resources, we wanted to avoid the necessity to obtain both an OlD and a UUID . It is possible to encode a U U I D in an oro, but the reverse is not true.
We cou ld encode a UUID in an OlD by registering an OlD prefix. The prefix would indicate that the
sequ ence after the prefix was a U U I D . U U I Ds are fixed-length structures generated from time sta mps and Ethernet addresses, and therefore arbitrary infor mation such as :111 OlD cannot be encoded in them.
UUIDs are also e::tsier tor application writers to gener ate because nu merous systems ship with tools to generate them.
Certain directory services, for example X . SOO, have external type definitions tor the directory entries.
lt
is possible to define a generic entry and then map arbitrary values inro that entry, but I DS entries would not be meaningfltl when viewed with the native di rec tory management tools. We fel t that this was unac ceptable, because it would make the management of I DS entries in the namespace much more difficult. Some systems use U U ! Ds to represent the type infor mation. We chose to use UU !Ds si nce they are both easy to generate and can be used in both U U I O and OlD class definition systems. The use of OIDs wou ld require U U I Ds to be generated for U U I D -based systems and mappings to be maintained .52
Com m unities An I DS com nH111irv i s both an adminis n·ativc grouping mechanism and ,1 logic:�! loc1tion for IDS resources. When people imcr�Kr wirh the I DS svs
rem, rhev sec a com m u n i rv as the org�mizing principle.
The �1dminisrraror contro l s rl1e bou ndaries �111d mem
bership of :111 IDS comi11UI1in·. T1·pic1llv, <1 com mun in·
represents either a p�1rticuL1r locnion such as a b u i l d
ing or a hmcrional grouping such a s :1 \\ Ork group.
I n iri�1lly, \\'C considered :1 supcrconrnt ro join multi ple directories inro :1 single logiol di rcctorv. This supercontnt wou ld ha1·c cont�1incd multiple contexts, one
r(n
c�1eh n•pc of resource su pported bv I DS . Wee1·enruallv subsu med the supcrconrot i mo a comrnu
n i n• :111d oiled it a resource COI1tor l ist. An IDS com mun in• is ston:d as �1 special object in rhe d i rectorv. F.ach community's resource comexr l ist describes rhc directories that 111�1kc up the com munirv. The resource context list is rhc kdcr:�rion mechanism by which I DS determi nes where resources of each type :�re stored . Each entry in the resource context list is �1 pair of resource type :�nd context. As users and applications oper:�rc on entries in :1 com munity, rhe I DS ti·amework
COMMUN ITY
(through IDS enrry and communit\' methods) inspects
the resource type and the comlnunin· to
d
ercnni ne the context. Figure 3 i l l ustrates an IDS comnu1 11in•.One of the problems we anticipated w�1s th�H large organizations ll'ould nat u rallv re nd to han: 111anv I D S
com muni ties: How wou ld r h c user idemi t-\· these; We
considered Jn additionJI h icr:�rchv in 11 hich com m u
nities ll'ou ld be mem bers o f other com m u n ities. Our usabi l i n· consultants cmpb;1sized that users should nor have to broll'se a hicrJrcll\' ro �Kcess resources . I n
response, we developed the concepts of t h e local ami
the home communin·. . The loc:�l com m un i n· is �1ssoci-.
atcd \\'ith rhe machi ne J user is curremlv using-it
represents a plwsical location . The home com m u11it)'
is the one with which the user is Jssociatcd or belongs.
vVe env
i
sioned rh:�t the home community wou ld bethe s:1me as the local communitv �1r the user's normal
place of work, b u t thet-c is t10 requirement inherent in
the design th:Jt things be orgJ n i zcd this W�1y. ror
example, if a user is associ:ncd with the com m u n i rv at
her work site and the nuc hinc she uses is :1lso Joc1tcd
at that 1vork site, both her Joc1l communi ty and
DEFAULT CONTEXT ---
Svc Provider Type = F7801 DB7-F675-1 1 CD-ABC2-08002B1 87D1 A (ODBC) External Name = IDS_Group Community
lnlernal Name = E \\tuxedo\idsodbc\idsdbdir.mdb Svc Provider Private = NULL
RESOURCE CONTEXT LIST RESOURCE CONTEXT CONTEXT OBJECT TYPE KEY:
c::::=J
COMMUNITYc::::=J
RESOURCE CONTEXT LIST-
RESOURCE CONTEXTc=J
OBJECT TYPECONTEXT
Figure 3
l DS Com m u n i tv
Svc Provider Type = EFF4B840-EC52-1 1 CD-9E5 E-08002BBA95CA (CDS) External Name = ids_cell.lkg.dec.com
Internal Name = ids_cel l.lkg.dec.com
Svc Provider Private = NULL
Svc Provider Type = C723E850-A 1 A6-1 OAB-A699-08002B361 FC1 (LDAP) External Name = c=us: o=dec;ou=IDS_Group Community
Internal Name = c=us:o=dec;ou =ID S_Group Community Svc Provider Privale = YUMMY, 386. TCP/IP
her home comnHmiry rqm:senr this \\'Ork sire. If this user works at another work site and uses a different m:1.chine, her home community remains the s:1me, but her loc;1l comtnunity rdlecrs the community wlH.:re
the new m:1chine resides. The concepts of local and
home communities do nor red uce the nu mber of com munities, but they do provide a d irect method bv \\'hich users can access the comm u nities that contain the resources the\' most hTquentlv use . The local :md home commu nities are a con,·en ience; users and :lppli cnions are in no wav restricted to those communities.
Search Support Searching is handled by the search object. The search object contains a commu nity ( or list of communities ) , :1 resource tvpe, and Jn attribute tiltcr. The attri bute til tcr supports both equalirv and comp:1rison matching of attribute val ues and allows c:1llcrs to construct complex requests by conc:�ten;Hing comparisons together in a series of Boole:�n opera tions. For example, a cal ler cou ld construct a tilrcr tlut returned all pri mer objects that ( ( ( are locJtcd on F loor2 ) OR ( are located on Floor3 ) ) A N D (sup port color printing) ) . Combi ned with the lou I :md home commu nity supporr, ti l tcrs allow applications :md users to express ideas such JS "print this at the closest printer that supports color, t\\'o-sided pri nting, :�nd then transmit it to ;l n\' bcsi mile machine in 111\'
home conHnu nirv. ''
The carch object's ddiult tiltcr returns all objects of the resource type in the locJI community. The search object resolves the community to a context :md passes it to the service provider. The service provider con structs a l ist of matching I I )5 cntrv objects to return to the user. In I DS, the search object supports browsing. The search object has mctl10ds that displ:�y a diJiog and construct tilrers bJsed on user input. vVhcn design ing the S\'Stem , we dcb:Jted whether it was bet ter f()r the se:1rc h object to cont<lin both the fil ter and rhe search d ialogs or whether the fi lter constru ction belonged in the IDS en try. We chose to keep the
search dialogs separate h·om the I DS entry. Experience
with i mplementing resources derived ti·orn the I DS enrn· h:�s shown this to be an error. Currently it is ncc css;ll'\' to derive ti·om two objects, I DS entrv and the sc1rch object, to implement a resource that has a resource-specific search dialog. We will be modirving the search and I DS entry objects so that the construc tion of the ti lters and the di:�log that constructs the ti ltcrs are I DS e ntry methods.
Schema The ser\'icc prm·idcrs transbte between the n:�ti,·e directorv object and the I DS en tn·. I n genera l , directory sen·ice entries arc n o t self-describing. I n existing directory services, either J schema or the applic:�tion is expected to know the d irectory-spccitic f(mnat of the data . The btter is more common than
the former, ,md in Jll\' case the schema methodologies Jre unique to uch directOr\' service .
From the poinr of \'iew of the native dircctorv ser vice, IDS is the appl ic:�tion. To properly convert the data, the se rvice providers must knmv what it is. The service pro\'idcrs usc the schema to determine the cor rect attribute <1 1ld \'J iue types to use when constructing the I DS entrv of;1 particular t\'pc .
The schema describes resource tvpcs, Jttri bu te tvpes, and attri bute \'alue data types. Logic:�l lv, the schema is a set of t:�blcs, one for each service provider, which maps the native nJme or type to the I DS name or type. These tables are read by the I DS schema com ponent when I DS is initialized. Bee:� use these tables are external to the system , thev can be modified by users or applicJtions.
There is one l i m i tation on the exte nsion of the schema: Ne\\' Jttribute and resou rce rvpcs can be ddined, but thev must be composed fi'om the prede fi ned IDS :lttri bute \'alue types that the scr\'ice providers can support. The service providers wou ld have to be mod i ticd to su pport Jddition�l attribu te va lue data types. This limitation is not as severe JS it :lt first appears. A rich set of data types is ddined in the existi ng dirccrorv sen·ices, and a relarivclv sm:\11 set is in common us:1gc. Bv defining the I DS data types ro encompass the set of Lhta rvpes ddined lw existing di rectory services, we have reduced this l i mir:� rion to J theoretical rather than a practical problem .
As a conseq uence of the use of schem:1, applications must specit)' rile resource type tor Jny I DS operation . This is a limitation that in principle docs not exist in other directory svsrems. After some consideration, we concl uded that kw usefu l operations can be performed on an object whose type is un known . To perfcm11 an operation on objects of all rvpes, the schema c:�n be i nterrogated t()J' the l ist of all supporred I DS object types, and the opcr:�rion is then iterated over each type.
The System Object The system object lo�1ds and