[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: gluing directories with draft-ietf-ldapext-locate-02.txt
Thanks for the response - but the SRV thing - well it still does not address
why directories are needed and the applications they serve - and the
information model designs that relate Users to Services....
regards alan
-----Original Message-----
From: Tom Jordan
Sent: Tuesday, May 16, 2000 11:46 AM
To: Lloyd, Alan; Sukanta Ganguly; Lloyd, Alan;
ietf-ldapext@netscape.com; Kurt@OpenLDAP.org
Subject: RE: gluing directories with
draft-ietf-ldapext-locate-02.txt
Sorry, but I have to respond to this one...
Customers assume that you've done the leg work and are delivering a
secure
system (I know - bad assumption, but...) If you offer an insecure
system as
an option, I think you've misrepresented some things (including what
current technologies can do).
I agree with the fact that current technologies are weak in the
security
aspect, but I still find the SRV option useful. Assume that I've
practiced
all of the due diligence necessary to protect data from anonymous
access.
Assume further that I've arbitrated trust relationships between
other
(similar) institutions. Is it not useful to be able to discover
services
for which I'm eligible?
I think there is a tendency to consider these deployments insecure
because
they place the onus of security on the implementer rather than the
protocol
designer. That's OK in my book (although it means some additional
work).
More options means more flexibility (and yes, more potential to
build an
insecure system, but whose job is it to watch after the bottom line
if not
the local admin's).
--Tom
At 08:09 PM 5/15/00 -0400, Lloyd, Alan wrote:
>The fundamental problem is LDAP servers and referrals are
absolutely useless
>if one has any notion of authenticating users and providing logical
>views/management of information across a distributed environment -
according
>to a trusted common authentication and ACI regime..
>
>Given the whole world has be beat up over the last three months on
the
>internet by unidentified users - why do these developments NOT
consider
>security in any approaches!!!! ??????
>
>
>Sorry - customers want commercial strength scaleable,
deterministic,
>distributed protected directory services - the proposal is
unworkable in
>this context..
>
>regards alan
>
> -----Original Message-----
> From: Sukanta Ganguly
> Sent: Tuesday, May 16, 2000 2:03 AM
> To: Alan.Lloyd@ca.com; ietf-ldapext@netscape.com;
>Kurt@OpenLDAP.org
> Subject: RE: gluing directories with
>draft-ietf-ldapext-locate-02.txt
>
> Alan,
> I did not read so deeply into Kurt's proposal. But from
what I
>understood, since the DNS SRV records were used for advertising
LDAP
>servers, one could easily leverage it for gluing directories. Not
to mention
>the fact that this will not be the ONLY approach that will ever
exists. If
>the LDAP server provides the smarts for doing so I think clients
would be
>pleased to get better referals. Don't you?
> I do agree with your views, and I think I get it
correct, that
>with the DNS SRV approach, proper "service" oriented advertisements
is not
>yet defined. I would like a better mechanism wherein services
hosted by LDAP
>servers are properly defined so that service vendors could use a
proper
>advertising template and provide the relevant information and I as
a service
>consumer could lookup the "NET" and with some good and smart query
tool
>exactly locate the service vendor who would be ready to service my
>requirements within the resource limits I specify. This is
analogous to the
>web approach taken today. I am thinking, dreaming and haven't had
any formal
>or informal discussions with anybody on this yet. I was planning on
sending
>an email to Bob Morgan/Paul Leach to run this idea by them and see
what they
>think about. This email actually brought me into the the mood of
writing
>this down and emailing it to everybody. Give me your thoughts on
this.
>
> SG
> sganguly@novell.com <mailto:sganguly@novell.com>
>
>
> >>> "Lloyd, Alan" <Alan.Lloyd@ca.com> 05/14/00 08:47PM >>>
> Is anyone concerned that "gluing directories with LDAP" is
only
>providing a
> system which is slow, has lots of overheads, is more
complex than
>X.500 and
> will only deal with publically accessable attributes for
non
>authenticated
> users.
> - ie one cannot put a consistent ,distributed
authentication and
>access
> control regime over this AND one cannot do predictable
(response
>time)
> distributed searches that are controlled/protected by the
server at
>the
> client access point - or provide "service" based
correlation of the
> responses according to User profiles or domain access
control
>settings.
>
> To me this is definitely not what "large scale" directory
users
>want...an
> unprotected, uncoordinated, non deterministic
"information"
>infrastructure
>
> Sorry - Just my views
>
> regards alan
>
>
> -----Original Message-----
> From: Kurt D. Zeilenga
> Sent: Saturday, May 13, 2000 6:10 AM
> To: ietf-ldapext@netscape.com
> Subject: gluing directories with
> draft-ietf-ldapext-locate-02.txt
>
> The intro to this draft states this may be used by
clients
> (or servers acting as clients). I'd like to add that
it
> may also be used by servers acting as servers to
generate
> appropriate referrals to requests not held by the
server.
> That is, if a client requests a DN not held by a
server,
> that server could use DNS SRV to produce a suitable
> referral to the client.
>
> I have an example of such a server operating
(experimentally)
> at ldap://root.openldap.org.
<ldap://root.openldap.org. > It
>will generate LDAPv3 (and
> LDAPv2+) referrals using the method similar to that
described
> in the I-D.
>
> Enjoy!
> Kurt
>
> // pseudo code: real code is available from OpenLDAP
public
> // source repository.
>http://www.openldap.org/software/repo.html
><http://www.openldap.org/software/repo.html>
> domain=NULL
> foreach( rdn of dn ) // left to right
> {
> if multiple value rdn {
> domain=NULL;
> continue;
> }
> if rdn attribute type == "dc" {
> if( domain != NULL ) {
> domain = concat( domain, "." );
> }
> domain = concat( domain, rdn value );
> continue;
> }
> domain=NULL;
> }
>
> if( domain != NULL ) {
> if( DNSSRV( domain ) ) {
> return referral;
> }
> }
> return noSuchObject;
>
>
>
>