| NSF
Middleware Initiative |
Robert
Banz |
| draft-internet2-mace-dir-inter-domain-data-exchange-00.html |
University
of Maryland, Baltimore County |
| Copyright
© 2002 by UCAID and/or the respective authors |
October
2002 |
| Comments
to: nmi-support@nsf-middleware.org |
|
|
Development of this document was supported with funding from the
University of Maryland, Baltimore County, Internet2, and the NSF Middleware
Initiative (Cooperative Agreement No. ANI-0123937).
|
|
Inter-Domain
Data Exchange
Abstract
This paper is an attempt to record thoughts on a type of problem in which
data elements must be transported, stored, or used across independent administrative
domains. Numerous issues arose in discussions of this problem space within
the Internet2 MACE-Dir working group. We have tried to present those deliberations
in this paper.
For additional information and related topics and resources see the following
sites:
| Internet2 Middleware Initiative: |
|
| MACE:
|
|
| EDIT:
|
|
| NMI: |
|
| |
|
3.1
Multi-Campus University System... 5
3.3
Visiting Medical Professional Records Access
3.5
Third-Party Authorizations
4.1.1 Intra-Domain
Identity Mapping
4.1.2 Inter-Domain
Identity Mapping
4.2
Data Plus Associated Metadata
5
Techniques and Alternative Solutions
5.3
Federated Access Control Methods
5.4
X.501 Knowledge References
5.5
Representing Attribute Meta-Data
5.8
Techniques for "Zero Knowledge" Identity Mapping
A.1
Assumptions about our Environment
A.1.1 An Object-Relational
View
A.1.2 Transport: Another
Assumption
A.2
The Duties of a Data Router
A.2.1 "And other
duties as assigned
B
Stitched Directories Proposal
1 Introduction
In today’s interconnected world, the need to access data across multiple
administrative domains is increasing. Students and faculty alike require
the appearance of a seamless environment between local and remotely hosted
services. Grant funding organizations require updated contact information
for research faculty. Recently, the INS requires universities to keep
them apprised of enrollment data regarding international students. Campuses
wish to pool resources, a step that requires federated identity management
that crosses existing administrative lines.
Many of these problems require techniques beyond the typical metadirectory
processes that are currently in use within campus infrastructures. While
time is taken to briefly discuss some of these, readers are encouraged to
become familiar with Metadirectory Practices for Enterprise Directories
in Higher Education (http://middleware.internet2.edu/dir/metadirectories/internet2-mace-dir-metadirectories-practices-200210.htm)
as many concepts discussed in depth in that document are built upon here.
The discussion within the MACE-Dir working group
from which this paper is abstracted was initiated by Michael Gettes’ “Stitched
Directories” proposal. The original “Stitched Directories” proposal is
included here as Appendix B.
There is also quite a bit of overlap between this problem space and what
is called Federated Identity Management. The Burton Group defines this
term as “the use of agreements, standards and technologies to make identity
and entitlements portable across autonomous identity domains” [DB02].
Several scenarios involving inter-domain data exchange are presented in section
3 below. Issues bearing on the requirements that a solution must satisfy are
collected in section 4. In section 5 some techniques are described that help
to further illuminate the problem space.
The MACE-Dir Working Group considers this a work in progress and warmly invites
readers to participate in its further development. The first step would be
to send an expression of interest to mace-dir-comments@internet2.edu.
This version of the document is published as an Internet2 Draft and will expire
in April 2003.
2 Terminology
AuthN: Authentication
AuthZ: Authorization
Data Sink: An endpoint of data flow, opposite of a Data Source.
Data Source: The source of a data flow, opposite of a Data
Sink.
Local Identity: The attributes, entitlements, etc., which are
associated with an identity specific to a single administrative or functional
domain.
Metadirectory: An architectural element that executes Metadirectory
Processes.
Metadirectory Processes: The processes by which source data
is captured, transformed, and presented in an enterprise directory. [TB02]
3 Scenarios
3.1 Multi-Campus University System
This scenario describes a multi-campus situation where each campus is independent
in so far as their computing facilities and identity management procedures
are concerned. However, they face growing demands to support integrated
services, they share some facilities, have a shared library system, and have
a high degree of multiple appointments, both faculty and student.
The shared library system directors, in particular, have expressed their
desire for a single interface for accessing and retrieving the various bits
of identity information for the members of this multi-institution community
regardless of their originating campus. Historically, the ‘branches’ of the
library system located at each campus have worked out interfaces to their
campus business systems. The form of these linkages varies from automated
data feeds to manual input.
At first glance, this is a classic metadirectory scenario. In fact,
most of the required procedures are those that you would use in a single institution
to map identifiers and ‘join’ identities (see the object identity mapping
requirement in Section 4 below). Two features of this scenario take
it beyond a classic metadirectory problem. First, existing campus-level
infrastructures remain complete and independent of each other. Second, there
is a need to capture metadata reflecting the originating sources of the data
being provided and associating the person and their roles to the appropriate
member institution(s) (see the data plus associated metadata requirement in
Section 4). As with all inter-domain data exchanges, there is a requirement
to specify a transport mechanism and a need for parties at the data sources
and the data sinks to have a shared language covering both information syntax
and semantics (see the transport and shared language requirements).
3.2 Funding Agencies
Many funding agencies, such as the National Institutes of Health, maintain
databases of current and potential Primary Investigators (PIs) who may be
applying for or currently working on projects funded by that institution.
Other organizations provide services to notify potential researches of pending
solicitations. Both of these functions require a way of searching current
research faculty information at hundreds of universities. Of particular interest
are contact information, current projects, and research interests of potential
grant recipients. In addition to sharing all the requirements of the
multi-campus system scenario, this scenario requires that the agency’s access
to institutional data be appropriately controlled and limited (see the federated
access control requirement).
3.3 Visiting Medical Professional
Records Access
This scenario describes access to resources including protected health information
by visiting health care providers, where they would not have or need a local
network user ID at the visited facility. For example, a visiting physician
(or other provider such as a nurse or laboratory technician) is given access
to specific patient records at a health care facility.
The visiting care provider (visitor) needs temporary
network access at the visited facility to securely log into their home facility
for identification and authorization. The home facility consults the
business agreement with the visited facility and present the visitor’s access
authorization based upon the rules contained in the agreement. The visited
facility grants appropriate access based upon the visitor’s presented credentials
and records details of all the visitor’s transactions and data access for
later audit if required.
3.4
Personal Address Book
Most people have some sort of "personal address book," either stored
in their desktop email client, on a PDA or scribbled on little scraps of paper
stuffed into their wallet. This is not a situation we commonly think
about in the directory space, nor would we go about solving this problem with
typical metadirectory functionality. However, the problem is an interesting
one, and it invites exploration of techniques to manage affiliations with
data sinks that spend much of their time in an off-line state.
The "holy grail" for personal address book management would be
to have the capability for on demand synchronization of personal information
that may have its authoritative source housed in various organizations’ directories.
The usage scenario would be similar to that of "syncing" a PDA with
a desktop system, except that instead of a single desktop machine, the PDA
syncs with various directories scattered across the Internet.
The requirement unique to this scenario is the need for resource discovery.
That is, there needs to be some mechanism by which the PDA client can discover
where to go to find authoritative, up-to-date contact information for the
individual entries in its address book.
3.5 Third-Party Authorizations
Jane Doe is a faculty member at Foo.edu. She is also a member of a professional
organization, Bar.org. Both Foo and Bar have contracts with vendor X providing
their members with access to specific licensed resources. Foo.edu has licenses
for products A, B, and C for use by its faculty, staff and students. Bar.org
has licenses for products B, C, and D for its members. When Jane sits at her
desk and accesses vendor X, she would like to be given access to all of the
products to which she is entitled, A, B, C and D. The content provider
may wish to receive authZ information only (for example, patron anonymity
is important in library-like situations.)
This scenario requires a method for federated access control, and a method
of associating attributes from multiple identity authorities. First,
a system needs to allow the content provider X to receive authentication and/or
authorization assertions from Foo.edu. The special challenge of this
scenario lies in how to get a trustworthy assertion of the person’s membership
in Bar.org to the content provider (see the data integrity requirement). Two
directions can be taken here, one where the authorization assertion is made
by Foo.edu, provided there is a mechanism where Bar.org is providing Foo.edu
with the information, and trusts Foo.edu to make such assertions on their
behalf. The second approach would rely on Foo.edu systems knowing that
to access X, Jane’s authZ process needs to make a pass through Bar.org to
pick up additional authZ assertions before hitting site X.
4 Requirements
4.1 Object Identity Mapping
Object identity mapping, for the sake of this discussion, is the procedure
by which it is determined that two or more digital objects represent information
relating to the same real-world subject. In current implementations,
the subject being referred to is most often a person. However, there
will be situations where the subjects being mapped between directories are
not people, but may be computers or "data objects" such as those
stored in a digital library. For each type of object, there will be
identifier attributes used to uniquely indicate a particular instance.
For example, a person’s name can be used to assert who someone is. Of
course one name, such as "John Smith," will map to any number of
people.
4.1.1 Intra-Domain Identity Mapping
From experience in dealing with identity mapping in reasonably manageable
populations, such as a college campus, we know that a name is not a good identifier.
A good identifier has the property of being globally unique across the population
and, even better, persistent through time. As discussed in Identifiers,
Authentication and Directories: Best Practices for Higher Education (http://middleware.internet2.edu/docs/internet2-mi-best-practices-00.html),
and Metadirectory Practices for Enterprise Directories in Higher Education
http://middleware.internet2.edu/dir/metadirectories/internet2-mace-dir-metadirectories-practices-200210.htm),
it is clear that most of these "good" identifiers tend to exist
only in one database or another which makes them generally bad candidates
for any kind of inter-domain mapping. Some campuses have taken to the
practice of issuing a "globally unique identifier" for members of
their population generated by their enterprise directory. However, such an
identifier is only for use within the campus community, and holds no meaning
outside of it. Thus it cannot be used for mapping when moving outside of the
institution.
In practice, intra-campus mapping has traditionally relied on using such
identifiers such as a "Student ID" number, or "Social Security
Number"[1],
and while the appropriateness of using such identifiers for mapping can be
argued, for most purposes it has been sufficient. Sufficient being defined
as: it works most of the time, and for the few times it doesn’t work the resulting
mis-mapping can either be easily fixed or completely ignored. However,
some institutions have gone further than using these identifiers to do mapping,
and check other attributes of an individual, such as their name, address,
date of birth, or phone number to verify the strength of their mapping decision,
or potentially reject it.
4.1.2 Inter-Domain Identity Mapping
Before discussing the intricacies of inter-domain identity mapping, there
are some basic questions that need to be asked:
·
Does our directory need identity mapping at all?
·
What is the scope requirement for identity mapping, all identities,
or a subset?
·
Does the identity mapping need to be automatic?
·
Do data source and data sink share identifying information?
The first question simplifies everything, if it is unnecessary to provide
any identity mapping function on the target directory, all of these problems
can be ignored. Many situations may not need any mapping functions at
all. Scenarios exist for which it is acceptable, even potentially desirable,
that multiple entries be made for the same individual if they enter the directory
from different institutions. This is the tack that the Directory
of Directories for Higher Education (http://middleware.internet2.edu/dodhe/)
has taken. The benefits gained from not mapping include simplifying
the data processing needed and adding to the privacy of the individual by
not identifying their potential multiple affiliations. On the other
hand, providing a mapping function could be integral for assuring an individual
is given all of the resources that they are entitled to, if the directory
is to be used for access control purposes; or to provide a one-stop-shop for
finding all of an individual’s contact information.
The second question is a follow-up to the first. The "scope"
in which you are performing identity mapping may also vary depending on your
need. For example, you may only need to identity-map faculty and staff,
and students may not need federated identities. Additionally, the "scope"
could be defined as "Folks from these institutions get their identities
mapped, but if they are from any other, they don’t."
A potential solution to this mapping problem for the multi-campus system
scenario would be to create a "bridge" identity management system
that would map identities existing at the institutional level to a single
person object, creating a multi-campus person registry. This would provide
a single-point for campuses to do lookups against when situations arise where
‘campus A’ is receiving, or requesting data from ‘campus B’, in which the
primary identifiers at the campuses differ.[2] By also exposing some basic affiliation
data in this registry, the library system would have a single data source
to feed their identity management system (and also find the most current billing
information for someone with overdue fines!)
When it is decided that some identity mapping needs to be done, the question
of making the mapping an automatic process is now on the table. Some
of the same advantages and disadvantages of doing mapping altogether are also
applicable to this decision. One direction to take with regards to the
choice to make the mapping manual is to assign this task to some number of
humans at an organization to apply appropriate mapping logic to each entry.
For obvious reasons, this is probably not a feasible option, as the staff
costs could be overwhelming, and even more error could be introduced to the
mapping decision. However, a potentially more appropriate use for "human
driven" mapping is one where the individual being "mapped"
would be involved in the decision. This is the road taken by the Liberty
Alliance in implementing their "reduced sign-on" system.[3]
Simplified, this approach requires the individual to authenticate themselves
to both data sources, "proving" that the identities listed there
represent him/her, allowing backend processes to "link" these identities.
The privacy benefits of this are obvious, as the decision to link identities
is completely in the individual's hands, and in the Liberty Alliance case,
there are procedures in the design for "breaking" the mapping at
the request of the individual. For applications such as reduced-sign-on
and the scenario where one may want to augment their institutional entitlements
to resources with those provided by other affiliations, the voluntary mapping
described here would fit well.
When it comes to automating an identity mapping process, strong drivers to
the success are policy matters, which may also intersect with personal privacy
and governmental regulations. The key factors are the policies regarding
what identifying information is available in the data sources, and what restrictions
are in place on making this data available to the mapping process. As
the attributes that are most useful for mapping, such as an individuals’ SSN,
date of birth, etc. are also typically the ones that are most closely guarded
by an individual and her affiliated institutions, this may be problematic.
However, if the situation inter-institutional directory being constructed
is of the nature that lends itself to this information being available, the
best practices that are in place in the intra-institutional environment may
be applied successfully in this space. However, when this information
is not directly available, some alternative methods of mapping may need to
be considered. One alternative is described later, in section 5.8.
4.2 Data Plus Associated Metadata
For data items to be successfully exchanged and used by multiple domains,
it is often insufficient to send a raw attribute-value pair. The data
item may need to be bundled with associated metadata that provides the context
for and characteristics of the information conveyed. In the multi-campus
scenario, to use a simple example, the affiliations of faculty and student
need to be associated with the campus that asserts them.
4.3 Data Transport
It is difficult to decide which task is more daunting in exchanging data
between differing administrative domains, the policy aspects, or the technical
hurdles. While the managers of the data can argue policy questions until
the end of the world, it is often assumed that the technical folks will be
able to hash out a solution in minutes. Of course this is rarely the
case. To make matters worse, the enterprises and systems that may be exchanging
data are quite disparate in their nature, add to that the potentially infinite
combinations of these relationships that a single site may need to be involved
in. All in all, you face a significant management challenge. Until
the day comes that there is a single standard for everything, all that can
be offered are recommendations as to how such problems may be made more manageable.
The method of transports available to get data from point "A" to
point "B" is highly dependant upon the specific problem to be solved.
Solutions can range from the simple FTP-ing a file from one site to another
on a daily basis, to complex message-oriented exchange techniques to implement
close-to-real-time data updates, or to relying on the remote repository to
request updates as it needs them. To add one more decision in to the
mix, the question arises of whether to "populate" the remote directory
at all or alternatively, to use techniques that allow the user/application
to gather the information in "real time" from the various data sources.
The transport may also be responsible for providing security for the
data, including basic access control, transport level encryption, and mutual
authentication of the transport endpoints. There seems to be very little
that can be done to limit the methods of data transport that may be required,
however, we recommend leveraging existing methods described in the Metadirectories
document, as well as some techniques that are discussed in section 5.
4.4 Shared Language
By "shared language," we refer to both the syntax and meaning of
an attribute/value combination. This is a difficult but solvable problem.
With work done with regards to LDAP, XML schemas, and other such information
interchange standards, there most likely exists work that spells out a way
to represent at least some of the data you wish to share with others.
It is our recommendation that you rely upon relevant standards when representing
your attributes to external organizations, and resist the temptation to make
data available directly in the format that best suits their needs.
Failing that, make it a community of interest project to define a shared
language, for example, by collaboratively defining a directory schema with
specifications for the semantics and intended uses of the attributes and values.
This is precisely what has been done within Internet2 with such object classes
as eduPerson and commObject.
By going this route, standards will be strengthened through use, and data
transformation code that may need to be written for a single relationship
may be reusable, instead of being a one-off effort. The receiving party
of the data should then be able to massage the data into any site/application
specific format that is suitable, or, hopefully, choose to use the data as
sent, in a standards-compliant form.
When exchanging person-related data, which is likely to be most of what is
to be exchanged, we suggest as a first step following the recommendations
conveyed in the eduPerson specification, which make suggestions as to the
use, syntax and meaning of common attributes including those from inetOrgPerson.
4.5 Federated Access Control
In the funding agency scenario detailed above, the home institutions of Principal
Investigators will not want to make all the data they hold about such people
available to funding agencies. There will be a select, negotiated set
of attributes to which the funding agency systems should be granted access.
The visiting medical professional scenario also requires that the visitor’s
home institution give only selective access to its records about the subject.
The federated access control solutions discussed in section 5 address this
requirement.
Some of the affiliation scenarios described in this paper revolve around
controlling access to content or procedures provided inter-institutionally
through web-based services. There are multiple methods either in use
or in development that can be utilized in these situations. However,
some scenarios, such as third-party authorizations (3.5) may require as-yet
undefined solutions. All of the methods described in section 5 below
rely on certain key technologies and standards, such as the Security Assertions
Markup Language (SAML), but each has unique aspects.
4.6 Resource Discovery
Resource discovery refers to the ability, in some automated or algorithmic
fashion, to determine where and how to access specific services or information.
In this case, the services that need to be accessed are those revolving around
retrieving data updates. For a situation such as the personal address
book scenario (Section 3.4), the ability to "find" the LDAP server
at an organization without necessarily knowing its IP address may be helpful.
Techniques such as DNS SRV records, which are described in section 5 of this
document, could be used for this purpose. However, other resource discovery
techniques such as UDDI (http://www.uddi.org) are more general purpose.
4.7 Data Integrity
The key to the usefulness of the data available in any directory is its correctness.
With that said, being able to provide the correct information in a directory
that is a compendium of data from multiple sources can be quite a challenge.
Some of the issues that first come to mind are:
·
Keeping in mind the data modification policies of the data sources.
·
Having the most up-to-date copy of a source’s data.
·
For identity-mapped objects, what happens when attribute values conflict?
Received data is only as good as it is at its source. When accepting
or using data that is not under your control, you need to have some assurance
that the data is correct. This assurance could come by several means,
the simplest of which is an out-of-band agreement with the custodians of that
data as to the nature of the assurance they can make regarding its integrity.
It is important as well that the minimum level of integrity of the data available
in the compiled directory be communicated to, and understood by, its consumers.
The level of assurance needed by a consumer may vary greatly. A directory
that is controlling access to medical data will require a high level of assurance
between all parties, as there may be legal and financial risk associated with
data being wrong. However, the level of assurance required to update
an email address in someone’s personal address book may be minimal, as the
risk associated may be very small. It may also be advantageous to have
a method of representing to a user the source of the data, as some applications
may require it.
Another vexing task in directory management is keeping data up-to-date.
Depending on the techniques in use to populate the directory, this may or
may not be as tough an issue to tackle. From an architectural standpoint,
one of the most desirable techniques for populating and updating would be
on a change-at-a-time basis. As this can be implemented so that data
is updated in a “real-time” fashion, assuming everything is working correctly
the target directory should have the most up-to-date information at any given
time. However, when it doesn’t work changes stop coming or some changes
are missed. When this occurs, we need some mechanism in place to either
note how old something is so that an application may make the decision that
the information provided to it may be stale and do “the right thing,” or provide
the processes managing the directory a basis for requesting an update to,
or potentially pruning data that has reached the limit of freshness.
A method of a data source “recommending” an expiration time for a data element
may also be of some help, as the originator of the data may have some knowledge
(not known to the recipient) of how often this information changes.
Some of these techniques are in use as part of DNS, whereby zones on secondary
name servers have intervals as to when they’re to be checked for updates,
and maximum time-to-live (TTL) values for how long a zone will be held if
requests for updates fail. Of course, robust inter-domain message queuing
services would be an ideal fit for this problem.
An important policy decision when creating a system that is to provide identity
mapping is what will be done when attributes for an object where there are
conflicting values for an attribute that occurs in two of the sources that
have data mapped to the same object. In the intra-domain situation,
these rules may have been very cut-and-dried, as institutional policies, or
other strong drivers may dictate what happens. For example, when dealing with
conflicting information between a Human Resources system and a Student Information
System, the data that is in Human Resources may automatically be chosen to
win-out, as it is a reasonable assumption that folks probably want to have
their paycheck delivered to the correct address. When bringing together
data from multiple external sources, the choices may not be as obvious the
data since sources are basically peers. So some other method of resolving
these discrepancies must be found. One, which may not seem so obvious
at first, is simply to present all of the options to the user of the directory
and let them choose. However, the usefulness of this may leave a little
to be desired. A second simple method is to choose the value that is
newer. Of course, the problem here is that many data sources do not record
the time an attribute was last changed. There is no easy answer to this
problem. What will be done in any situation will vary based on the nature
of the relationships between the data providers, and the meaning and intended
use of the attributes that are in question.
Further discussion on this can be found in Section 5.5 (Representing Attribute
Meta-Data), as how and what information can be asserted about an attribute
is directly related to the integrity of the attribute itself. Stitched
Directories (Appendix B), also makes an attempt to tackle basic data integrity
issues.
5
Techniques and Alternative Solutions
5.1 Batch Updates
For situations that require that data be transferred to a central directory,
the simplest, and probably the most popular method, consists of large batch
updates of the data. This technique is probably in use, in some form,
in everyone’s architectures, and may consist simply of FTPing a file in a
specific format from the source system to the consumer. While this technique
doesn’t go far in keeping data as fresh as possible (your data is only as
good as the frequency of your last batch update), for many needs it is sufficient.
We recommend, however, that while it is important to keep things simple,
do not simplify them so much that data security is ignored. FTP, unless
used in a very controlled environment, such as a VPN, is not a secure method
of transport. Simply using scp (part of OpenSSH, or other Secure Shell
implementations) instead of FTP is a substantial upgrade in the security of
your transport.[4]
If scp is not available, encrypting the data with an application such as GnuPG
or PGP is also an option.
5.2 Real-Time Joins
A “real-time join” refers to the coalescing of data from multiple sources
at the time that it is to be used. This covers an entire class of techniques,
such as those that rely on an application to contact multiple data sources
to produce the ‘full picture’ of an object, to those that may use a middleman,
or a broker, to accomplish this task.
Assuming that identity mapping functions are provided in some manner, all
of the appropriate information about an object MAY be gathered by executing
LDAP queries across the services provided by the source institutions.
The application may even discover the locations of such servers through their
DNS service records (cf. section 5.6).
However, putting this functionality in a user application may not be appropriate.
Placing these functions in a service that acts as a broker, and allowing a
user application to access it via a protocol such as LDAP, or as a web service
application, may also be done.
5.3 Federated Access Control Methods
5.3.1 Shibboleth
Shibboleth is a software package and specification built upon SAML that enables
a user who is authenticated by a site (foo.edu, the origin site) to have specific attributes
asserted by a party at foo.edu, and have that assertion understood,
and trusted by bar.edu (the target site) another site participating
in a Shibboleth “club.” More information regarding the Shibboleth project
and its specifications can be found at http://middleware.internet2.edu/shibboleth/.
In its current version, Shibboleth is not able to aggregate assertions about
a single user from multiple attribute authorities so it is not a standalone
solution to the third-party authorization scenario described above.
Shibboleth concepts could provide the basis for an access control mechanism
for the PDA address book scenario. A potential method would be to allow
the issuing of entitlement attributes which grant access to specific directory
objects and which could be revoked at any time by the subject. An architectural
element such as the Data Router (5.7) may be the appropriate mechanism to
provide access to data through such means, as LDAP (without extension) would
most likely not be sufficient.
5.3.2 Liberty Alliance
The Liberty Alliance is an industry consortium founded in part to develop
methods for federated identity management. More information, and specifications
for the Liberty Alliance protocols can be found at http://www.projectliberty.org.
Currently, the protocols revolve around procedures to manage bindings between
multiple network identities existing on Liberty Alliance-enabled web sites,
through trusted parties known as “identity providers”. Authenticating
to an identity provider provides you a single-sign-on environment between
multiple sites. Liberty does not currently address sharing attributes
of an identity between sites. This functionality is currently slated to appear
in a future release of their specifications. However, what is well-described
are methods in which affiliations between identities at multiple locations
can be created, managed, and potentially broken, under the control of the
person in question.
5.3.3 WS-Security
WS-Security (Web-Services Security) is a specification developed primarily
by Microsoft and IBM that has now been turned over to OASIS for finalization.
Its focus is to specify a standard method of transport for security credentials
in a web services environment. Currently, the encapsulation and transport
of Kerberos and SAML credentials are covered. While it does not provide
methods for establish trust in a cross-realm environment, it will be an emerging
method of transport for higher-level authN and authZ assertions.
5.4 X.501 Knowledge References
The term knowledge, as used in the X.501 documents refers to “DSA
[Directory Service Agent] operational information held by a DSA that it uses
to locate remote entry or entry-copy information” [IT01]. A knowledge
reference is “Knowledge which associates, either directly or indirectly,
a DIT [Directory Information Tree] entry or entry-copy with the DSA in which
it is located” [IT01].
In summary, a knowledge reference is a representation of where a piece
of knowledge may be found. Knowledge references make up part of, and
rely on, a complete X.500 environment to function, as discussed in the specification.
However, the terminology used with regards to the types of references discussed
in Section 10 of ITU-T Recommendation X.501 and the model on which
they are based may suggest new approaches to a standards-based inter-domain
data exchange model. This is an area of active investigation by the
MACE-Dir Working Group.
5.5 Representing Attribute Meta-Data
Many of the requirements derived from the scenarios above require that certain
other information regarding an attribute, or collection of attributes, be
made available to a data consumer, or the processes managing a database itself.
The information that may need to be represented includes, but is not limited
to:
