[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
hyperDEN01
The attached README text describes the contents of a gzip'd tar archive
which contains the Directory-Enabled Networks Schema (version 3.0c5),
along with various extensions to the schema and information model.
The schema, along with the schema extensions, is provided as attribute
and objectclass tables, in formats suitable for implementation in ISODE
X.500/LDAPv3 (and derivatives) and OpenLDAP. This includes a
representation in the BNF notation specified by X.500(93), as used
in RFCs 2252, 2256, and others.
The source tables and scripts used to produce the tables are also
included, and may be adapted to produce attribute and objectclass
tables in other formats.
Please share comments, subsequent developments, and tales of emergent
behaviors via this channel.
The hyperDEN01 distribution is:
ftp://ftp.openldap.org/incoming/bartz-den-19990401.tar.gz
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz | |
# lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, |
# | Ooo, ooo, oooooo! |
# | I've got a gnu attitude! |
# voice (317) 226-7060 | |
# FAX (317) 226-6378 | |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
hyperDEN01
an exposition of the DEN Schema, version 3.0c5
and
various extensions to the schema and information model
Larry Bartz, Internal Revenue Service, Indianapolis, IN, USA, 26 March 1999
1. Introduction
1.1 Process and Motivation
Extend DEN schema and information model for additional
functionality
Produce DEN schema and extensions in implementable formats which
are immediately useful without further extension
Inspire further discussion and use of DEN, as an "open"
specification, not strictly the domain of commercial
products
Jumpstart "open" implementations of DEN
Collect and use the tools and enhancements which emerge from
this process
1.2 Caveats
1.2.1 Read Up
If you haven't read the DEN specification, get yourself a copy
BEFORE you attempt to digest this material. The latest version
is available (at the time of this writing) at:
http://www.murchiso.com/den/
1.2.2 No Magic
Many of the objectclass interdependencies and attribute
interpretations described in this information model are not
explicitly supported by directory protocols. There is no particular
magic at work in this model, nor is any particular magic necessary.
The directory is a repository of information. The information is
maintained as the state of the objects which the directory holds.
It is the responsibility of entities outside the directory (such
as devices, programs, and people) to interpret the states of the
objects and behave as the information model describes.
2. Features
2.1 Complete DEN Schema, as per DEN 3.0c5
attribute and object class tables for:
LDAPv3: in the same format as the LDAP RFCs
X.500: tables suitable for ISODE and derivatives
(the LDAPv3 production works for the LDAPv3 side, too)
LDAPv2 emulation of DEN schema for OpenLDAP
2.2 Supports all DEN relationships, as described in DEN 3.0c5
2.3 Introduces a flexible, user-level typesafe (or at least type-
-intention-revealing) relationship model, based on object
oriented design principles
2.4 Adds support for Services to possess credentials for authentication
2.5 Extends profiles for:
reduced reliance on containment as a relationship mechanism
mechanism to include other profiles
enhanced scalability and reusablity
2.6 Adds profile types for role- and location-based profiles
2.7 Adds capability to apply the DEN "management suite" of
attributes to DEN and non-DEN objects
2.8 Includes the source tables and tools which were used to
produce the implementation tables. These may be adapted to
produce attribute and objectclass tables in various other
formats.
3. First Principles
3.1 Represent the DEN 3.0c5 schema as faithfully as possible
3.2 Extend DEN in a natural and "legal" way
3.3 Finding is better than searching or listing
3.4 Excessive reliance on containment makes for brittle relationships
and limits opportunities for reusability of objects
3.4 The authorization to manipulate the content of all objectclasses
must be manageable.
3.6 This is "a" DEN schema implementation, not necessarily "the"
DEN schema implementation.
4. Schema and Information Model Extensions
4.1 Introduction
The schema extensions are in the general areas of profiles,
relationships, policy conditions and authorization control for
directory object management.
4.2 Profiles
4.2.1 General Comments
The aim of extending the DEN profiles is to fully enable
their use in effecting access controls (or authorizations)
for services.
DEN 3.0c5 specifies profiles for user, group,
organizationalUnit, and organization. hyperDEN01 adds
profiles for role (for role based access control, or
RBAC) and location. The extension of the DEN UserProfile
also effects a name change to hyperDEN01-clientProfile,
reflecting its appropriateness for representing clients
other than humans.
The extended objectclasses are described in terms of
the additional attributes they possess.
4.2.2 hyperDEN01-authorizedPrincipalsList
This multi-valued DN-type attribute designates the principals
who are designated for this profile.
It allows for a relationship coupling without containment.
4.2.3 hyperDEN01-includeProfileList
This multi-valued DN-type attribute designates other
profiles which are included in this profile.
It provides a mechanism for scalability and reusability.
For example, consider a hyperDEN01-clientProfile, which is
contained in a person object. The includeProfileList
could designate several profiles which this person shares
with others, such as role, location, and organization.
These included profiles would not be contained in person
objects and so their lifecycle would not depend upon the
existence of any person object. Likewise, the attribution
of these profiles to a person would not be contingent
upon the person's object existing within any particular
directory containment hierarchy.
4.2.4 hyperDEN01-includingProfileList
This multi-valued DN-type attribute designates profiles which
include this profile, assuring that profile relationships
can be navigated from end to end, beginning from either
the client or the service.
4.2.5 hyperDEN01-mutexProfileList
This multi-valued DN-type attribute designates profiles
which are mutually exclusive with respect to this profile.
It provides a mechanism for preventing inadvertant
delegations of authority which might otherwise occur
via administrative error or naive inclusion of other
profiles.
This attribute is not intended to specifically deny all
profiles to which the principal is not entitled. Rather,
it should be used to specifically deny those profiles
which pose a particular threat or difficulty with respect
to the current or intended profile.
4.2.6 Summary
The information model for these profiles constitutes a
special case of a relationship between clients and
services. Clients and services say "I'll meet you at the
profile."
Clients are connected to the profile relationship via
an initial containerized hyperDEN01-clientProfile. This
profile may or may not specify some services directly.
This initial profile can be augmented by encompassing
additional profiles by DN references via the includeProfile
attribute. Note that the hyperDEN01-clientProfile is
appropriate for any entity which might act as a client
on the network, persons and services alike.
The client can use the profile as a least privilege
navigation guide to network services, such as via a menu
which is constructed at runtime from the client's profile
state.
Services are connected to profiles via the
hyperDEN01-profileAuthorizationPolicyCondition, which is
described in 4.4.1, below. Given its list of authorized
profiles, a service (or another service acting in its
behalf) can compare to the profile state of a potential
client, and thereby determine whether the client is
authorized. Recall that the DEN information model implies
that a service will contain a Policy object. The policy
object participates in a relationship, called
ContainedPolicyConditions, which relates a policy to
policy conditions.
4.3 Relationships
4.3.1 General Comments
This relationship model intends to accomplish two goals.
First is to provide a flexible, extensible, reusable
relationship model for use in DEN and elsewhere.
Second is to support the quality of typesafety in
relationships among directory objects; again in DEN
and elsewhere.
4.3.1.1 flexible, extensible, reusable
The hyperDEN01 relationship model is configurable, via
the states of its objects (values of their attributes),
to support realtionships of binary, ternary, quaternary
orders and beyond.
Each of the collaborators in these relationships can
consist of one or more objects; again configurable by
the states of the objects, without need for extension
of the objectclasses described below. The cardinality
of the relationship collaborators can be controlled or
ignored.
As a result, the classic 1-to-1, 1-to-many, many-to-1,
and many-to-many relationships are all achievable from
this set of general purpose objectclasses.
Moreover, this model can represent virtually unlimited
extensions and permutations of classic relationship
models. Consider 1-to-M-to-M, M-to-M-to-M-to-1, or
2-to-7-to-9, or more, or less, or whatever.
The model is asserted to be sufficiently expressive and
precise, so as to be capable of supporting the implemen-
tation of all of the relationships described in DEN
3.0c5 without further extension.
For use by DEN, each of the relationships described in
3.0c5 is defined as its own unique objectclass which
inherits from the base type, but differs only in name
and OID. This strategy is intended to assure the
typesafety of the relationships.
4.3.1.2 desperately seeking typeSafety
Despite our widespread use of the term "object" when
describing the targets of aliases and DN attributes,
the truth is that they point to directory entries.
A directory entry is not strongly typed. As a container,
it can contain any object type (be a member of any
object class) which has been stored there. An entry
which is a member of the person objectclass is often
also a member of the organizationalPerson objectclass,
and may also be a member of the inetOrgPerson objectclass.
And what if the entry also belongs to any of a myriad of
auxiliary object classes? When you refer to this entry,
do you care about them, or not?
Today, when you point to that particular entry with an
alias or a DN attribute, you see all three objectclasses.
What will your alias point to tomorrow, or next month, or
a year form now? It will still point to the same
container, but the contents may be very different.
And what if your code is following a DN reference
created by someone else's code, created for an entirely
different purpose from what you have in mind? What will
your code find when it gets there (to the realted entry)?
What did the original creator of the link intend?
This relationship model introduces a mechanism (via
schema) and a semantic (via information model) for
effecting and assuring typesafe relationships among
objects in the directory.
In this model, all relationship participants (nodes)
are required to assert their type. Of course, this
assertion can and should be compared to the current
schema at the time of critical events.
Relationship collaborator aggregations are constrained
such that all of their members are of the same type. So
if you want to create a M-to-M-to-M relationship in
which the three collaborators are aggregations of
apples, oranges, and pears, you can be assured that
there will not be a banana hiding in one of the baskets.
Relationship nodes in this model can protect themselves
from referencing or being referenced by inappropriate
relationships. So, for example, we can prevent trained
monkey objects from being related to the management
organizational role. Sorry, Zimbu.
4.3.2 namedAndTypedRelationship objectclasses
4.3.2.1 relationshipNodeConnectorRefAuxClass
This auxiliary objectclass may be applied to any
objectclass which is to participate in this relationship
model as a node in a relationship.
This auxiliary objectclass is the node's gateway to
all relationships in which it participates.
The relationshipNodeConnectorList attribute is a multi-
valued DN type, which points to one or more
relationshipNodeConnector objects.
4.3.2.2 relationshipNodeConnector
An instance of this objectclass represents exactly one
node. The node it represents is explicitly named by
DN in the single-valued nodeObjectName attribute. The
node's objectclass (OID) is asserted in the single-
valued nodeObjectType attribute.
The multi-valued relatedObjectTypeConstraint, if
populated, limits the types of objects the node
may be related to.
relationshipCollaboratorList is a multi-valued DN
attribute which maintains a state list of all the
relationshipNodeAggregator objects which refer to
this node connector.
minimumCardinality and maximumCardinality attributes,
if populated, limit the number of objects the node
may be related to.
4.3.2.3 relationshipNodeAggregator
Instances of this objectclass are the principal
collaborators in relationships. An instance of this
represents an aggregation of nodes. The nodes are
constrained to all be of the same type. A node
is represented in this aggregation by one of
its relationshipNodeConnector instances.
nodeObjectTypeConstraint is a single-valued OID
attribute which specifies what kind of node may
be aggregated in this.
The relationshipNodeConnectorList attribute is a multi-
valued DN type, which points to one or more
relationshipNodeConnector objects. This is the
aggregation.
relationshipList is a multi-valued DN type which
maintains the state of which and how many relationships
for which this is a participant or collaborator.
minimumCardinality and maximumCardinality attributes,
if populated, define the number of nodes which are
represented by this aggregation.
4.3.2.4 namedAndTypedRelationship
This objectclass represents the relationship.
relationshipType is the OID of this objectClass. It
can be used to distinguish this objectclass and its
attributes from others which might inhabit the same
entry.
relationshipCollaboratorsList is a multi-valued DN
attribute which maintains the state of which and how
many collaborators are involved in this relationship.
The degree attribute precisely defines the number of
collaborators which must participate in the relationship.
4.4 PolicyCondition
Two extended PolicyCondition objectClasses are included.
4.4.1 hyperDEN01-profileAuthorizationPolicyCondition
The hyperDEN01-profileAuthorizationPolicyCondition is
to be related (via Policy) to services which take advantage
of the profile based authorization model. This policy condition
contains a multi-valued DN-type attribute which represents
the profiles which are authorized to use the service. By
enforcing this policy condition, the service can fulfill its
responsibility to restrict access to only those principals who
possess the authorized profile(s).
4.4.2 hyperDEN01-timeSensitivePolicyCondition
The hyperDEN01-timeSensitivePolicyCondition contains a
reference to a TimeOfDayValidity object. The service can
consult this object to enforce access restrictions based on
time and calendar considerations.
4.5 Management Attributes
4.5.1 General Comments
Until LDAPv3 includes a standard for managing the directory,
implementors and users of directory services must devise
and manage their own solutions. Anyone who implements this
particular aspect of the hyperDEN01 model should be
willing and anxious to discard it when the appropriate
standards are implemented.
4.5.2 Description
DEN 3.0c5 described four relationships which are intended
to represent entities which are responsible for managing
the objects in the directory and the real assets (if any)
which those directory objects represent. These are the
AdministeredBy, BackupAdministrators, CanConfigure, and
Owner relationships.
The hyperDEN01 information model treats these relationships
as a special case. They are not included in the general
relationship model. Three significant considerations imply
this approach.
First, these attributes bear a unique relationship to the
object which contains them. They are intrinsically related.
If they were related to their target object by containment,
who would manage the container? Who would manage the
reference to the container?
Next is an obvious requirement for all directory objects
to have the capability to be managed.
Third is the fact that "owner" already has a canonical
syntax and semantic in X.500 and LDAP. It is an attribute of
type DN and it means "owner of the object".
The solution is to define each of the relationships as
a DN attribute, and include all of them in an auxiliary
class. This class can be applied to any directory entry,
thus conferring at least a designation of manageability.
Just as described in DEN 3.0c5, these attributes are
intended to point to a supportContact object. The
hyperDEN01 schema includes such an object, which is
modeled after a thread of discussion of the DEN AHWG.
4.6 Credentials for Services
The hyperDEN01-credentialedService objectclass adds password
and certificate attributes to Service, so services may
authenticate to the directory and to others. Hierarchical
descendants of Service must include an objectClass value for
this type (become members of this objectclass) in order to take
advantage of this feature.
4.7 AccountingService and AuditingService
The DEN AccountingService and AuditingService each possess an
attribute which is intended to represent the principal for
whom the auditing or accounting is being performed. These
attributes are typed as strings. hyperDEN01 adds attributes
of the same name, but with a "hyperDEN01-" prefix, and with
a DN type. The objectclasses are similarly extended with the
same prefix. They include the DN-type attributes. With these
extended objectclasses and attributes, the "principal" can
more readily be identified in the directory.
5. Limitations
5.1 The LDAPv2 production for OpenLDAP implementation is, at best,
an emulation of the DEN schema.
Because of the limited number and types of attribute syntaxes
currently available in OpenLDAP (and its UMich progenitor),
many of the DEN atttributes cannot be represented in a fully
typesafe manner. As it has always been with these directory
implementations, it is the responsibility of the implementor
and the user-level code to assign and interpret many values
in ways which cannot be guaranteed typesafe by the directory
implementation itself. The attribute table included with this
transmittal includes comments to guide the user in this matter.
Another limitation of the freesource LDAPv2 directories is
their innate inability to support attribute and objectclass
type inheritance. This can be overcome, to a certain extent,
as is demonstrated in the objectclass table. Follow the
guidelines to assign values to the objectClass attribute, and
an appearance of objectclass inheritance will be enabled.
Nevertheless, the attribute and objectclass tables contain
all the attributes and objectclasses specified in 3.0c5 and
by these extensions. If used carefully, it will perform in much
the same manner as an LDAPv3 implementation.
Notice that the objectclass table under the OpenLDAP tree
makes dandy documentation. Nowhere else in these docs or DEN's
docs will you see more clearly the accumulation of attributes
as you skate down the inheritance tree. The attribute table
has the most readable form of the attribute descriptions, as
well.
I am eagerly anticipating an opportunity to produce these tables
for the LDAPv3 version of OpenLDAP, when it appears.
5.2 Unilateral Editorializations inflicted against DEN 3.0c5
Some of these things just couldn't pass...
Elided redefinition of canonically (X.500/LDAPv3) defined
"name" attribute. Any standard LDAPv3 implementation will
already have this one defined. My server coughed this
up, right away.
Elided definitions of canonical (X.500/LDAPv3) attributes
cn, o, objectClass, ou, seeAlso, serialNumber. As above,
we really don't need to define `em twice.
Moved ReceivedDSByteCheck from PolicyCondition to
NetworkingPolicyCondition; just because...
Changed all instances of "Top" to "top". "top" is canonical.
"Top" is...something else.
5.3 Could require minor or substantial revision when/if the
DMTF publishes additional DEN specs.
6. Colophon
No, I didn't keystroke those tables!
7. The Name
The "hyper" part of the hyperDEN01 name partakes of two of the
dictionary's definitions.
One of the meanings is "beyond". As an extension, hyperDEN01 is
beyond DEN by definition. Whether it is beyond in the proper
direction is left to your judgement.
Another definition for "hyper" is "exists in a space of more
than three dimensions". One of hyperDEN's consistent themes is
that of breaking out of or avoiding traditional directory containment
hierarchies. hyperDEN01 supports the strategy of dimensional data
modeling for the directory, thus imparting multidimensional qualities
to its objects.
8. Summary
This stuff is complex. DEN is complex. The hyperDEN01 extensions heap on
more complexity, in the name of making the processes more specific.
Only the most dedicated mind-melding keyboard wizard could ever aspire
to maintaining all this complexity "by hand" through a general purpose
directory editing interface.
Write programs, objects, and distributed objects to implement the logic
necessary to make all this wonderful stuff happen. Share these with
your friends. Be the first on your block to collect `em all!
Larry Bartz, Internal Revenue Service, Indianapolis, IN, USA, 26 March 1999