Enabling the Internet White Pages Service - the Directory Guardian
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Enabling the Internet White Pages Service - the Directory Guardian
David W Chadwick & Andrew J Young
University of Salford
IT Institute, University of Salford, Salford, M5 4WT, England
Abstract 258 organisations listed, 126 being universities, research
The Internet White Pages Service (IWPS) has been slow laboratories or other publicly funded institutions, 82
to materialise for many reasons. One of them is the being commercial organisations whose primary business
security concerns that organisations have, over allowing is related to IT, with only 50 listings being for other
the public to gain access to either their Intranet or their types of commercial organisation. This contrasts quite
directory database. The Directory Guardian is a firewall dramatically with the large number of widely varying
application proxy for X.500 and LDAP protocols that is types of commercial organisation that have a presence on
designed to alleviate these fears. Sitting in the firewall the Web. Given that commercial organizations
system, it filters directory protocol messages passing outnumber universities by over a thousand to one, the
into and out of the Intranet, allowing security former are conspicuous by their absence in the IWPS.
administrators to carefully control the amount of Indeed, private discussions with a number of commercial
directory information that is released to the outside organizations that do operate X.500 or LDAP directories
world. This paper describes the design of our Guardian reveal that these organizations are willing to connect to
system, and shows how relatively easy it is to configure the IWPS in order to retrieve directory information from
its filtering capabilities. Finally the paper describes the it, but never to give directory information to it. Those
working demonstration of the Guardian that was built for commercial organizations that have joined the IWPS
the 1997 World Electronic Messaging Association have usually only participated in a half hearted way, by
directory challenge. This linked the WEMA directory to adding no more than a token entry or two. It was this
the NameFLOW-Paradise Internet directory, and realization, coupled with the growing demand from
demonstrated some of the powerful filtering capabilities commercial organizations to have a firewall system,
of the Guardian. running a number of application proxies, positioned
between their corporate Intranet and the Internet, that
1. Introduction lead to the development of the Guardian DSA. The
Guardian is a firewall directory application proxy, that
Experience gained over the last seven years with the intercepts all directory protocol messages between the
Internet White Pages Directory Service (IWPS), has Internet and the organization’s Intranet, and only allows
shown that universities and other public institutions are through those messages that the local security policy has
primarily the only organizations that are prepared to sanctioned (see figure 1).
publish their entire directories on the Internet. These are
the only organizations that have joined the Internet Directory
pilot/operational service in any significant numbers. For
example, in the UK NameFLOW-Paradise service [1]
there are 147 organizations listed, the vast majority of
which are universities, research organizations and
publicly funded institutions. Only 21 entries are of
commercial organizations, and of these, the majority are Guardian
computer hardware, software and telecommunications
suppliers, or consultancy companies specialising in
computer communications. Only 2 entries are of
commercial organisations whose main businesses are
unrelated to IT, e.g. electricity generation. Similarly
(although to a lesser extent) in the US IWPS there are Intranet Directory
Figure 1. Positioning the Guardian Directory Firewall
1 of 10The Guardian DSA development project started in 2.1. Filtering Rules
December 1995, with funding from the EC IV
Framework RTD program. The Guardian was originally It is important to realize that the Guardian itself does
designed to intercept only X.500 [2] protocols i.e. DAP, not hold any directory entry information, but rather holds
DSP, DISP and DOP, but with the recent wide a set of rules that dictate which directory information (in
acceptance of the LDAPv2 protocol [3] in the market the form of directory requests and responses) can flow
place, coupled with the rapidly expanding market for between the Internet and the Intranet. In this respect, it is
stand alone LDAP servers, support for inbound LDAPv2 quite independent of any access control information that
protocol has also been added to the Guardian. Support may be applied internally to the database holding the
for outbound LDAPv2 protocol will be added later this directory information. Indeed, it would be possible to
year. operate the local directory service with little or no local
access control information, thereby giving employees
2. The Functionality of the Guardian free access to most of the corporate directory, and to
place all the controls in the Guardian, thereby restricting
The Guardian provides two quite distinct services to access to everyone else (i.e. the hard shell and soft inner
the private Intranet1. First and foremost, the Guardian is model of security). The rules that drive the Guardian are
a directory application proxy designed to run in a derived from the overall security policy of the
security firewall system. It ensures the integrity and organization.
confidentiality of directory information on the Intranet, The filtering rules that are configured into the
by only allowing properly authorized directory messages Guardian operate at a number of levels, and are
to flow into and out of the Intranet. separately configurable for each direction of information
Secondly, the Guardian is the Intranet’s directory flow. One configuration file (ToSecurityDomain.ini)
gateway to the outside world, acting as a connectivity contains the rules for filtering requests originating from
enabler, particularly for standalone LDAP servers. It is the Internet, and the other configuration file
in this second context that organizations running LDAP- (FromSecurityDomain.ini) contains the rules for filtering
only directories can gain real administrative benefit. requests originating from the Intranet. At the highest
LDAP clients and servers will no longer need to be level, the security administrator configures which
continually re-configured to learn about other LDAP protocols e.g. LDAPv2 and DAP, are allowed to pass
servers on the Internet - they only ever need to know through the Guardian. At the next level, the security
about their own internal LDAP servers and the administrator configures which users are allowed to bind
Guardian. All new configuration information is added to with these protocols, and below this, which operations
the Guardian, making it a central point for e.g. Search and List, are allowed to pass through the
administration and knowledge management. The Guardian. So for example, the integrity of Intranet
Guardian builds up its own ‘world’s eye’ view of the directory information can be protected by forbidding
IWPS, and has its own internal skeleton DIT from which modification operations that originate from the Internet.
it hangs knowledge references to other LDAP and X.500 At the next level, the administrator configures which
directory servers. If operating in a purely X.500 context, entries are accessible to which operations, and by which
the knowledge configuration information is extremely alias names they should be known in the other domain.
simple (one of the Intranet’s DSA’s must hold a superior Below this, the administrator lists which attribute types
reference to the Guardian, and the Guardian must hold a may be included in particular entries, and at the lowest
superior reference to NameFlow Paradise). In a mixed level, the administrator configures which attribute values
LDAP and X.500 context, references to external LDAP are allowed to pass through the Guardian. Thus
servers are also added to the Guardian. confidentiality of information is assured by preventing
The remainder of this paper will concentrate on the sensitive attributes, entries and even the names of entries
security functionality of the Guardian and will describe from leaking out to the Internet. All filtering rules have a
its powerful filtering capabilities. default of DENY everything, so that the administrator
has to progressively release the locks in order to let
directory information leave the Intranet.
Because an application proxy has no inherent way of
knowing whether a request has originated from the
1
Like any firewall, the Guardian can sit between any two networks, Internet or the Intranet, the Guardian is configured with
protected by different security policies. For the purposes of this paper, we the names and addresses of trusted directory servers on
only consider the case of the publicly accessible Internet (representing a
low security network) and a corporate Intranet (representing a high both sides of the firewall. Every other directory server is
security network).
2 of 10assumed to be un-trusted and residing on the Internet. signature proves to be false, will either reject or
Note that trusted directory servers on the Internet are still downgrade the operation according to the security policy
not allowed to receive sensitive information from the input by the administrator.
Intranet unless an encrypted communication session is 3.1.1. Authenticating and Authorising Outgoing
employed. Finally, the Guardian will never relay requests Operations
within one of the domains, as none of the directory Some organizations have a requirement to restrict the
protocols require this functionality. (A consequence of number of users who are allowed access to the Internet.
this is that the Guardian will never relay a request from The security administrator has to configure the Guardian
one unknown directory server to another.) with the distinguished names of users and non-leaf nodes
(typically organizational units) that are allowed access to
3. User Authentication and Authorization the Internet directory. If the Intranet user is not within
this name space his request will be denied. Finally, for
In a distributed directory service, a user may bind to authorized users, the DN of the user can either be hidden
and be authenticated by any directory server, and the (for example by replacing with a generic name) or made
servers may pass user requests between themselves (in visible in the requests that flow onto the Internet. An
the X.500 model the DSP is used for this, whereas LDAP X.500 user will typically bind to his/her local DSA, and
currently does not support such a protocol). A the request will be chained to the Guardian by this. In
configuration parameter informs the Guardian of the some circumstances the user will need to bind directly to
minimum level of authentication required for each the Guardian, for example, when using LDAP servers, or
directory protocol. If the user meets this minimum level, when external directory servers wish to directly
the bind will be accepted, otherwise it will be rejected. authenticate the user. In these circumstances the
In the case where the user does not bind directly to the Guardian acts as a proxy user. For these outgoing
Guardian, the Guardian needs to know if a particular sessions, the Guardian performs DAP-DAP chaining or
user was authenticated by a trusted directory server, or by LDAP-DAP chaining (see figure 2). Outgoing DAP or
an un-trusted one. Its list of trusted directory servers will LDAP to DSP chaining is not supported. LDAP-LDAP
tell it this, and if it transpires that the user was chaining will be added towards the end of this year,
authenticated by an un-trusted server, then the Guardian although the same functionality can be obtained now by
removes the authentication privileges from the user’s using the X.500 Enabler from Critical Angle [5].
request and treats him or her as un-authenticated before 3.1.2. Authenticating and Authorising Incoming
either rejecting the request or passing the DSP request Operations
onto the other network (see figure 2). If the user was For incoming sessions, a similar situation applies. The
authenticated by a trusted directory server, then his/her Guardian is configured with the list of remote users (DNs
level of authentication (simple or strong) is believed and of leaf and non-leaf nodes) who are allowed to access the
passed on as-is to the other network. Intranet. It is also possible to give blanket access by
If the user binds directly to the Guardian, then his/her using the keyword ALL. Because the Guardian is trusted
credentials are checked. If simple (password based) by the Intranet directory servers, it does not need to act
authentication is used, the Guardian checks the password as a proxy for a remote user. The remote user must be
against its internal list (the passwords are actually stored authenticated by the Guardian before he/she is allowed
as attributes of user entries with the equivalent access to the Intranet. Consequently the Guardian always
distinguished names). If strong (digital signature based) performs standard DAP-DSP chaining or LDAP-DSP
authentication is used, the Guardian checks the signature chaining (see figure 2) on incoming operations. LDAP-
for authenticity, and also that there is a chain of trust LDAP chaining will be added towards the end of this
leading from the public key of a trusted CA to the public year to support LDAP stand alone directory systems on
key of the user. In this context, our Guardian is shortly the Intranet.
due to become a certified user of the ICE-TEL CA
infrastructure [4]. If the user’s credentials prove to be 3.2. Processing of Referrals
false or untrustworthy, a configuration parameter directs
the Guardian to either reject the bind or downgrade the It is important that the names and addresses of the
session to un-authenticated if this level is acceptable. corporate directory servers can be hidden from the
In addition to session authentication, individual Internet, and that only the address of the Guardian server
directory operations can be digitally signed by a user. is made known publicly. Referrals to Intranet directory
The Guardian will check the digital signatures of signed servers would compromise this situation, if they were to
operations, retrieving the CRLs as necessary, and if the be released to the Internet. Consequently, the Guardian
3 of 10always acts on referrals to Intranet servers. Similarly for Internet. Again, the Guardian will always endeavour to
incoming referrals, there is little point in passing these to follow incoming referrals, and pass a complete set of
the corporate user, since he has no direct path to the directory information back to the user.
Internet Directory
DAP LDAP DSP
DAP LDAP
Guardian
DAP LDAP DSP LDAP
Intranet Directory
Figure 2. Protocol Chaining Supported by the Guardian
The filters act sequentially, as depicted in Figure 3.
3.3. Configuring the Guardian Configuration of the Guardian involves the
specification of two distinct security policies:
One of the key factors in security is KISS (keep it • the Intranet Access Policy (this specifies the protocols
simple, stupid). If it is extremely complex to configure a and operations that external users can use to access
firewall system of any type then it is likely that, sooner or the internal domain; and the entries, attributes and
later, a security administrator will make a mistake which values that can be returned in outgoing results); and
compromises the security of the Intranet. Consequently, • the Internet Access Policy (this specifies the protocols
ease of configuration has been a key design aim for our and operations that internal users can use to access
Guardian. the external domain; and the entries, attributes and
The Guardian acts as a 6 stage filter, progressively values that can be returned in incoming results).
refining and reformatting messages that pass through it.
4 of 10Attribute Attribute
Protocol User Operation Entry
Type Value
Filter Filter Filter Filter
Filter Filter
Figure 3. The Filters of the Guardian
To make clear the fact that these two policies are (if this is different to the
called domain)
distinct, two configuration files are specified, and each
contain specifications for all six filters. The syntax and ::= boolean condition in terms of
previous filters. The format is
semantics of each is the same, though it is very likely specific to each type of filter.
that the content will be different e.g. see Appendix 1.
The Guardian configuration uses a "default deny" 3.5. Examples
principle, which means that anything that is not
explicitly enabled will be disabled. Therefore, if both This section gives an example of each type of filter,
configuration files are empty then the Guardian will not and shows some of the capabilities that are possible.
allow any X.500 or LDAP protocols to pass through it.
3.5.1. The [protocols] filter
Additionally, by ensuring that only permitted actions are
Here, the list of enabled directory protocols is given.
specified, rather than prohibited actions, the
configuration file does not contain any prohibited [Protocols]
information and so it can be made public if required. ONLY DAP, LDAP(no authentication), DSP(simple)
3.4. Specification of the filters Each protocol may take an optional argument
indicating the minimum bind strength of authentication
The syntax for each filter is formally defined (using that is acceptable. In this example, a DAP bind must be
BNF) as: strongly authenticated (this is the default if no bind
strength is mentioned), an anonymous LDAP bind is
::= '[' ']' acceptable and a DSP bind must have at least a password
(simple).
::= 'Protocols' DISP and DOP are not mentioned, and the Guardian
| 'Users'
| 'Operations' will block any DISP or DOP binds that it receives.
| 'Entries' 3.5.2. The [users] filter
| 'Attribute Types'
| 'Attribute Values' This specifies the distinguished names of the users
who are allowed to bind to the Guardian for each of the
::=
[ ]
above protocols. Distinguished names are specified
according to Internet Draft draft-ietf-asid-ldapv3-dn-
::= [ 'FOR' ] 03.txt [6] (which will shortly supersede RFC1779), with
::= 'ALL' the extension that names may be specified using wild
| 'ONLY' cards. Four forms of wild card are supported:
| 'NONE' 1) if an RDN of “at=*” is included in the name then it
::= [ ',' will match any single valued RDN of attribute type
] at, e.g. cn is used for commonName etc.;
::= [ '(' 2) if an RDN of “at=**” is included in the name then it
')'] [ 'KNOWN AS' will match any multivalued RDN of where one part of
] the RDN is of attribute type at;
::= description of the items 3) if an RDN of “*=*” is included then it will match
accepted by the filter. The exactly one RDN of any attribute type; and
format is specific to each
type of filter.
4) if an RDN of “**=**" is included then it will match
one or more RDNs, of any attribute type, up to the
::= a restriction, allowing an item end of the name.
to be accepted under specified
conditions. The format is
specific to each type of filter. [Users]
FOR Protocol=DAP, LDAP
::= description of the item in the ONLY
(simple) KNOWN ASYoung,o=University of Salford via , Technology Institute,o=University of
Salford,c=GB> KNOWN AS (strong)
In the above example, only two entries (for the authors
Each user DN is followed by two optional parameters. of this paper) may pass through the filter, and these will
The first indicates the level of authentication that this be visible in the other domain with their organisational
particular user or group of users must present. If absent, unit affiliations stripped off.
it defaults to that specified for the individual protocols,
3.5.5. The [attribute types] filter
but can be set to a higher level if the security policy so
Here we specify which attribute types will be allowed
directs. A lower value will be ignored (as would be the
to pass through the Guardian.
case for DAP in the examples above, since the DAP
The second part of the example is needed if the
protocol requires strong authentication).
administrator wishes to over-ride the default-deny stance
The second parameter, starting with keywords
and say that all attribute types can be released for all
KNOWN AS, allows an alias name for the user to be
allowed entries other than those explicitly named in the
used in the other domain.
first part of the example.
3.5.3. The [operations] filter
Here, we specify which directory operations will be [Attribute Types]
FOR Entry=
users. ONLY objectClass, commonName, surname,
title, postalAddress, postalCode,
[Operations] telephoneNumber, userid, rfc822Mailbox,
FOR User= favouriteDrink
ONLY READ(unsigned),LIST(unsigned 20, signed FOR Entry=*
100),COMPARE ALL
3.5.6. The [attribute values] filter
Each operation may take an optional argument Here we specify, for each attribute type, the values
indicating whether or not it may be unsigned in order to which are allowed to pass through the Guardian. The
pass through the Guardian. The LIST and SEARCH example here specifies that all direct dial telephone
operations additionally can specify an optional argument numbers will be made available in international format,
giving the maximum number of entries that may be whether they are stored in international, national or
returned in the results (this may be different for signed internal format. Non-direct dial extensions (these do not
and unsigned operations). The default value for this is start with a 5) will not be released.
one entry. In this example, READ may be unsigned, The second part of the example is needed to over-ride
COMPARE must be signed (this is the default if no the default-deny stance and say that, for all other allowed
signature requirement is mentioned), and LIST may attribute types, all values can be released.
return more entries if the operation is signed. In the specification of a value, a * may be used to
SEARCH and the modification operations are not match any number of characters, and a ? to match a
mentioned here, and so these operations would not be single character.
allowed to pass through the Guardian.
[Attribute Values]
3.5.4. The [entries] filter FOR Attribute Type=telephone number
Here, we specify which entries will be allowed to pass ONLY "+44 161 745 *",
"0161 745 *" KNOWN AS "+44 161 745 *"
through the Guardian. In addition to specifying which "5????" KNOWN AS "+44 161 745 ????"
entries can pass through, it is also possible to specify FOR Attribute Type=*
what their names should be known as in the external ALL
domain i.e. a form of aliasing. This is especially useful if
an organisation wishes to protect its Intranet DIT 3.6. Specification of local names
structure from being visible on the Internet.
The configuration file allows the Guardian
[Entries] administrator to define local names for groups of users,
ONLY
KNOWN AS , easier for the administrator, since he/she does not have to
6 of 10re-enter lots of DNs. As well as allowing for more 4. Piloting the Guardian
readable specifications, the mechanism also provides a
single place where the names of the group members is The Guardian was successfully piloted at the EMA
defined, thereby making maintenance and audit easier. meeting in Philadelphia in April 1997, and again at the
Local names are defined in an extra section of the EEMA meeting in Maastricht in June 1997. It is now
tailor file, which is usually located after the filters permanently operational, and demonstrable from our
(though it can be located anywhere). They are specified Web site [7].
as follows: Because the Internet White Pages Service and
NameFLOW-Paradise service use Quipu based X.500
[Local naming]
NAME ... KNOWN AS products, that incorporate Internet defined extensions to
the X.500 1988 protocols [e.g.8], WEMA decided to set
up a parallel infrastructure using products that conform
The short local name must not contain a comma, an = to the LDAPv2 protocol and 1993 X.500 standards. The
or a *. Guardian is quite happy to talk to both flavours of X.500
The distinguished name may contain wild cards, as products, and in fact does so in our demonstration, with
defined earlier in the document. Any number of names the Salford directory (representing the Intranet) being
may be specified, separated by a comma. held in a Quipu DSA, and the WEMA directory
infrastructure (representing the Internet) being held in
An example is:
1993 conformant DSAs.
[Local Naming] If we were to connect the University of Salford
NAME , KNOWN AS the University of Salford directory, as directed by our
security policy. Furthermore, it would not be possible to
This allows the Guardian administrator to say: verify the full protection effects of the Guardian, because
no-one from the Internet would have access to the
[Users] unfiltered directory. Consequently, we have built a
ONLY (strong)
configuration that allows users to see both behind and in
to restrict use of the Guardian to just the named people, front of the firewall, so that they can see for themselves
or to say: the effect of the Guardian. To do this, we have added
subordinate knowledge references to the EEMA GB DSA
[Operations]
FOR User=
to point to both the University of Salford operational
ALL DSA, and the University of Salford Guardian (see figure
FOR User=* 4). By displaying the contents of the University of
ONLY Read,Compare,List
Salford operational DSA, one will see the entire directory
to give the named people higher privileges than other of the University of Salford. By displaying the contents
users. If staffing details change then the Guardian filters of the University of Salford via the Guardian DSA, one
do not need to be changed. will only see the entries that our security policy has
decided should be available to the public directory.
3.7. Other configuration information
Various other parameters are supported in the
configuration files. Briefly these are: a parameter to
control the amount of logging, whether to downgrade or
reject failed authentications, the list of trusted DSAs, and
the action to take if a request attempts to retrieve
restricted information (remove from result or return
error).
7 of 10EEMA
GB DSA
C=GB
University of
Salford via
Guardian DSA O=University of Salford via Guardian
University of
Salford DSA CN= person’s name
Figure 6 The University of Salford’s DIT visible
Figure 4. The Configuration of our Demonstrator
to the public
4.1. The University of Salford Directory
There are approximately 26,000 entries held in the This shows the powerful filtering effects of the
University of Salford directory, and these are all held in a Guardian, in that not only can it remove leaf entries and
single Quipu DSA. The Salford directory tree is subtrees from public view, but it can also remove non-
structured with departments (organizational units) below leaf nodes, thereby appearing to alter the structure of the
the University of Salford entry, and people below the corporate DIT. Finally, the Guardian can rename non-
departments, as shown in Figure 5. leaf nodes, thereby allowing the private directory and the
All people within the University of Salford have access public directory to use different naming conventions (for
to all of this information from the corporate Intranet. The example, in our demonstration, the internal name
Guardian has been configured so that the WEMA public O=University of Salford, is given the name O=University
directory can only see 3 person entries in the University of Salford via Guardian in the public directory). The
of Salford directory, and cannot see any of the Guardian thus allows you to gateway between two DITs
departments, as shown in Figure 6. with different name-spaces. Such capabilities are not
normally provided by standard access control lists.
C=GB
4.2. Attribute Filtering by the Guardian
The three entries that are visible via the Guardian have
had some of their attributes filtered from public view. If
O=University of Salford you read the contents of the entry:
CN=D W Chadwick, OU=Information Technology
Institute, O=University of Salford, C=GB
via the operational University of Salford DSA, you will
.... OU=department name
see that the Email address, Fax number, Telex number
and Telephone number attributes are all present.
However, if you read the contents of the entry:
CN=D W Chadwick, O=University of Salford via
Guardian, C=GB
... ... CN= person’s name
via the Guardian, you will see that the Telex number and
Fax number attributes have been filtered out. It is also
Figure 5. The University of Salford’s DIT possible to filter particular attribute values, if your
security policy so requires.
8 of 104.3. Performance [8] Hardcastle-Kille, S.E. “Replication and distributed
operations extensions to provide and Internet directory
A limited number of performance measurements have usingX.500”, RFC 1276, Nov 1991
been carried out in our laboratory, in which the Salford
DIT was searched for SN=Chadwick, both directly and Appendix 1. Example Configuration Files
via the Guardian. These have revealed that the deviation
in real time performance (as seen by the user agent), for # This is an example ToSecurityDomain.ini file,
both access routes, is as great as the delay in going via # specifying the Intranet Access Policy used in
# the EEMA demonstration Guardian (enhanced to
the Guardian. Specifically, for 20 requests sent via both # take account of some new features that are not
routes, the average time and standard deviation for a # currently implemented)
response was 15.5±6.5 secs for a direct request and # This file specifies the protocols and
20.3±7.5 secs for a request sent via the Guardian. We are # operations that external users can use to
currently performing additional tests to determine how # access the internal domain; and the entries /
# attributes / values that can be returned in
much of the delay is caused simply because we are # results (incoming operations outgoing results)
chaining via another directory server, and how much is
[Protocols]
actually caused by the filtering functionality of the ONLY DSP(simple),LDAP(no authentication)
Guardian.
[Users]
ALL
5. Conclusion
[Operations]
FOR User=,
The provision of a Guardian directory application ONLY Read (unsigned), List (unsigned 100, signed
proxy should give organisations that wish to publish only 100), Compare(unsigned)
a part of their corporate directory, the confidence to FOR User=*
connect their corporate directory service to the Internet ONLY Read (signed), List (signed 100),
White Pages Service, safe in the knowledge that they can Compare(signed)
fully filter the amount of directory information that [Entries]
leaves their domain. The Guardian implementation built ONLY KNOWN AS ,
at Salford University provides such a functionality. KNOWN AS
the two configuration files, used to input the
[Attribute Types]
organisation’s security policy into the Guardian, are both FOR Entry=
easy to understand and secure in the way that they ONLY objectClass, commonName, surname, title,
operate, using the default deny principle. postalAddress, postalCode, telephoneNumber,
userid, rfc822Mailbox, roomNumber, userClass,
userPassword, favouriteDrink
FOR Entry=*
References ONLY objectClass, commonName, surname,
organizationName, countryName, localityName,
stateOrProvinceName, street, title,
[1] Details about the NameFLOW-Paradise service can be
obtained from http://www.dante.net/nameflow.html
postalAddress, postalCode, telephoneNumber,
[2] ITU-T X.500 | ISO 9594 (1993) The Directory, Parts 1 to 9. userid, rfc822Mailbox, roomNumber, userClass,
[3] Yeong, Howes and Kille. “Lightweight Directory Access lastModifiedTime, lastModifiedBy,
Protocol”, RFC 1777, March 1995 accessControlList, associatedDomain,
[4] Details about the ICE-TEL project can be found at businessCategory, description, iattr,
masterDSA, slaveDSA, userPassword,
http://www.darmstadt.gmd.de/ice-tel/ favouriteDrink
[5] Details about Critical Angle’s X.500 Enabler can be found
at http://www.critical-angle.com [Attribute Values]
[6] Wahl,M., Kille,S., Howes, T. “Lightweight Directory FOR Attribute Type=favouriteDrink
ONLY tea, coffee
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names” , April FOR Attribute Type=objectClass
1997 ONLY top, person, organizationalPerson,
[7] For a live demonstration of the Guardian, see newPilotPerson, quipuObject, organization,
domainRelatedObject, quipuNonLeafObject,
http://fw4.iti.salford.ac.uk/ice-tel/guardian/demo organizationalRole, organizationalUnit,
country, locality, dsa
FOR Attribute Type=telephoneNumber
9 of 10ONLY +44 161 745 *,
0161 745 * KNOWN AS +44 161 745 *,
5???? KNOWN AS +44 161 745 ????
FOR Attribute Type=*
ALL
# End of filters - the following items are basic
configuration items
[General]
LOGGING "level=exception level=notice
file=guardian/intranet.log"
AUTHENTICATION downgrade
QUERY PROHIBITED ITEM return error
[Local Naming]
NAME KNOWN
AS
NAME KNOWN AS
# This is an example FromSecurityDomain.ini
# file, specifying the Internet Access Policy
# used in the EEMA demonstration Guardian
# (enhanced to take account of some new features
# not currently implemented)
# This file specifies the protocols and
# operations that internal users can use to
# access the external domain; and the entries /
# attributes / values that can be returned in
# results (outgoing operations incoming results)
[Protocols]
ONLY DSP
[Users]
ONLY
(simple) KNOWN AS
[Operations]
ALL
[Entries]
ALL
[Attribute Types]
ALL
[Attribute Values]
ALL
# End of filters - the following items are basic
configuration items
[Trusted DSAs]
NAME
(simple)
[General]
LOGGING "level=exception level=notice
file=guardian/internet.log"
AUTHENTICATION downgrade
10 of 10You can also read
