[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Implementation of V3 referrals and references

To: "Steve Sonntag" <VTAG@novell.com>
Subject: Re: Implementation of V3 referrals and references
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Fri, 28 Apr 2000 10:19:05 +0200
Cc: <openldap-devel@OpenLDAP.org>
In-reply-to: <s9081c37.066@prv-mail20.provo.novell.com>
Steve,

I've been avoiding messing with this code pending
IETF work in this area.  However, it's evident that
we need to push forward with something.

I believe the rebind callback approach, in general,
is inappropriate due to security considerations.
The application should have control over the complete
chasing process, this starts with choosing which
URI to chase, which servers to connect to, etc.

I see three basic approaches:
	A) sync routines return set of response(s) from
	THE server.  Apps manage referral chasing as
	needed.

	B) sync routines call callbacks upon RECEIPT
	of referrals and search referrals.  Apps manage
	referrals chasing as needed.

	C) sync routines manage chasing of referrals,
	callbacks at each step of the chasing process
	[choosing to chase, what to chase, bind, TLS,
	etc.] must be provided to allow application
	control.

Problem with C is that that process of chasing may
differ greatly from application to application and
so the set of callbacks needed to provide application
control might be quite difficult to define. 

I prefer implementing A and B [they can coexist].
If no callback is provided, the API returns the
referrals/references as results.  If a callback is
provided, the API provides the referrals/references
upon receipt.

Of course, the general objection to such approach
is that simple applications are harder to write.
I believe this can be resolved by providing better
tools (routines) and, if desired, a "directory"
level abstraction and API layer.  [That is, the
low level [current] abstraction should be at the
protocol session layer].

Kurt

At 10:53 AM 4/27/00 -0600, Steve Sonntag wrote: 
>>>>
I have completed the implementation of LDAP
V3 referrals and search references and will
submit a patch in a few days after we have
completed additional testing.
  
When we examined the rebind procedure
functionality, we realized that it doesn't
seem to meet the needs of V3 systems. In the
current V2 mechanism, when a referral is
received, the SDK calls the application
rebind procedure which returns to the SDK
username and password.  The SDK then performs
an ldap_bind_s using these credentials.
  
LDAP V3 supports multiple varieties of bind,
viz. ldap_simple_bind, ldap_sasl_bind, plus
variations left over from LDAP V2.  In
addition to additional parameters like
controls, server credentials, and etc.
ldap_sasl_bind may require multiple
interactions with the server to complete a
bind operation.  For some operations on V3
bind is not required at all.  I could not see
a way to make something analogous to the
current mechanism fit these needs.
  
I would like your comments, suggestions, or
flames on what we eventually implemented.  We
are using the current mechanism to register
the rebind procedure using
ldap_set_rebind_proc.  We thought of using
ldap_set_option, but realized that there is
no way to enforce compiler type checking on
the rebind proc definition using
ldap_set_option, where the
ldap_set_rebind_proc does do type checking.
  
The definitions from ldap.h are as follows:
  
/* V3 REBIND Function Callback Prototype */
typedef int (LDAP_REBIND_PROC) ( LDAP *ld,
     LDAP_CONST char *url, int request, ber_int_t msgid);
  
LIBLDAP_F( int )
ldap_set_rebind_proc LDAP_P((
     LDAP *ld,
     LDAP_REBIND_PROC *ldap_proc));
  
The rebindproc has four parameters:
    ld - the session handle
    url - the url string of the referral that
          caused the rebind procedure to be called
    request - the type of LDAP request being
          processed that caused the referral or search
          reference, for example LDAP_REQ_SEARCH
    msgID - the message id of the operation
          being performed.
  
When the SDK calls the application rebind
procedure, it is up to the rebind procedure
to perform a synchronous bind (or not perform
a bind) according to the requirements of the
application.  It is up to the application to
provide the rebind procedure with access to
appropriate credentials.  If the bind
succeeds or is not required, the rebind
procedure returns LDAP_SUCCESS to the SDK, or
any other error code if not successful.
  
When a referral rebind fails, the application
request (ldap_search_s, etc) is ended with an
LDAP_REFERRAL error code.

When a search reference rebind fails, the
reference is returned with the other search
results.
  
If no rebind procedure is registered, the SDK
performs an anonymous ldap_bind_s.
  
We tried to give the application everything
we know about the referral.  
  
Using ld and perhaps msgID, the application
could find context specific information
associated with the operation based on an
application specific mechanism.  We
considered using ldap_set_option with a (void
*) pointer and a matching ldap_get_option to
save context specific data in the ld and make
it available to the application, but felt
went beyond the requirements of referrals and
requires further discussion.
  
The referral url could allow the application
to decide whether to follow the referral
based on subnet or other information
contained in the referral.  The application
can use the ldap_url_parse function to pull
the referral apart into its various
components.
  
The request type gives the application
information as to what request type caused
the referral.
  
-----------------------------------------
We also changed the semantics of the
ldap_set_rebind_proc a little.  We put it
into the options area and treat it exactly as
an option, i.e. if NULL is specified for the
ld parameter, then it is set in the global
options area and will automatically be
registered for any new ld created when
ldap_init is called.
  
-----------------------------------------
  
One problem with this and the current
mechanism, is if the application requires
interaction with the user to get credentials,
the LDAP SDK thread may be suspended for
perhaps a very long time.  Currently this is
something the application must deal with. 
Perhaps in the future, a thread could be
spawned when the rebind procedure is called. 
In the current SDK code, there isn't any
threading being done at all, so something
like this could considerably complicate the
SDK.
  
Thanks for your comments,
  
Steve Sonntag,
Consulting Engineer,
Directory Services
Novell, Inc.
  

  
<<<<
References:
- Implementation of V3 referrals and references
  - From: "Steve Sonntag" <VTAG@novell.com>
Prev by Date: Implementation of V3 referrals and references
Index(es):
- Chronological
- Thread