|
Home > Archive > Apache Directory Project > September 2005 > [jira] Commented: (DIREVE-265) delegating binds to custom partitions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[jira] Commented: (DIREVE-265) delegating binds to custom partitions
|
|
| Trustin Lee (JIRA) 2005-09-22, 2:45 am |
| [ http://issues.apache.org/jira/brows...action_12330156 ]
Trustin Lee commented on DIREVE-265:
------------------------------------
Thank you for your patch first of all, Norbert. But can I know the use case of this patch? BIND operation is used only for authentication and AuthenticationService performs it already. Is there any reason to delegate bind operation to interceptors and
context partitions? Any ideas are appreciated.
> delegating binds to custom partitions
> -------------------------------------
>
> Key: DIREVE-265
> URL: http://issues.apache.org/jira/browse/DIREVE-265
> Project: Directory Server
> Type: New Feature
> Components: server main
> Environment: jdk1.4.2
> Reporter: Norbert Reilly
> Assignee: Alex Karasulu
> Attachments: delegate_bind.patch
>
> I have created a patch which permits SimpleAuthenticator to optionally delegate bind calls to the custom partition matching the DN provided to a bind call. This seems like the right general approach to take, but there were some points I wasn't completel
y certain about (being a noob):
> 1) I pass the credentials in as a Object (rather then byte[]) to allow for future flexibility when SASL support is added to DS.
> 2) The bind() call returns an InitialContext which SimpleAuthenticator immediately closes, rather then say returning a boolean. This seems sensible though.
> 3) Given the new bind() call is only optionally implemented by a ContextPartition, the default bases classes return null when it is called. A NotImplementedException type approach would work just as well, but I am unsure how the relative pros and co
ns are preceived by the core DS developers (runtime cost versus cleanliness).
> I also realise that the bind call is only one of a number of delegations that will eventually need to be supported to custom partitions, but hope that this patch isn't heading in the wrong direction and thus compromising any future work that may be requ
ired.
> If the patch is deemed useful, but further work is required due to any/all of the reasons above (or some I haven't considered) then let me know.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
| |
| Norbet Reilly 2005-09-22, 2:45 am |
| Hi Trustin,
My interest in creating the patch is a custom partition that proxies to an
external LDAP server. Hence I want to use the proxied server's
authentication if the DN presented to the bind() matches the proxy
partition's suffix and otherwise authenticate against ApacheDS's user store..
Note that the custom proxy partition additionally has some credentials
stored locally, which it uses to discover the remote LDAP schema and add
matching entries to the GlobalRegistries at server start-up time. Hence the
intention behind the patch is to allow access to the remote proxy partition
without having to duplicate all of its users inside ApacheDS.
Having said that, the only reason that I touched the interceptor code was
by necessity as ContextPartition was impacted by the addition of the bind()
method (and wanted to dispatch to it using the ContextPartitionNexus). I'm
not that familiar with the code yet, so please let me know if I changed more
then I needed to.
As I've mentioned to Alex in a previous posting; I'd imagine that
ultimately the core server might delegate a number of services to custom
partitions (authentication, schema (rather then a single top-level static
schema have one under each partition that has its own) etc). Hence although
I know this patch is only a small isolated step in that direction, it may be
useful to anyone else implementing a proxying custom partition.
Thanks
| |
| Trustin Lee 2005-09-22, 2:45 am |
| So all LDAP operations are required to Interceptors and ContextPartitions to
make ApacheDS fully function as an LDAP proxy server, right? WDYT, other
guys? It looks like a good reason.
Trustin
2005/9/22, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> Hi Trustin,
> My interest in creating the patch is a custom partition that proxies to
> an external LDAP server. Hence I want to use the proxied server's
> authentication if the DN presented to the bind() matches the proxy
> partition's suffix and otherwise authenticate against ApacheDS's user store.
>
> Note that the custom proxy partition additionally has some credentials
> stored locally, which it uses to discover the remote LDAP schema and add
> matching entries to the GlobalRegistries at server start-up time. Hence the
> intention behind the patch is to allow access to the remote proxy partition
> without having to duplicate all of its users inside ApacheDS.
> Having said that, the only reason that I touched the interceptor code was
> by necessity as ContextPartition was impacted by the addition of the bind()
> method (and wanted to dispatch to it using the ContextPartitionNexus). I'm
> not that familiar with the code yet, so please let me know if I changed more
> then I needed to.
> As I've mentioned to Alex in a previous posting; I'd imagine that
> ultimately the core server might delegate a number of services to custom
> partitions (authentication, schema (rather then a single top-level static
> schema have one under each partition that has its own) etc). Hence although
> I know this patch is only a small isolated step in that direction, it maybe
> useful to anyone else implementing a proxying custom partition.
> Thanks
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
|
|
|
|
|