|
Home > Archive > Apache Directory Project > February 2006 > [ApacheDS] How to use Interceptor.bind() ?
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 |
[ApacheDS] How to use Interceptor.bind() ?
|
|
| Endi S. Dewata 2006-02-22, 5:45 pm |
| Hi,
I'm currently using a custom authenticator to handle bind operations and
it's been working just fine. I noticed that a bind() method has been added
to Interceptor and I'm wondering if I should use this instead. I've tried to
implement the method in a custom interceptor but am not getting good
results. Here's the code:
public void bind(
NextInterceptor nextInterceptor,
Name bindDn,
byte[] credentials,
List mechanisms,
String saslAuthId) throws NamingException {
boolean authenticated = ...
if (!authenticated) throw new LdapAuthenticationException();
// call next interceptor?
nextInterceptor.bind(bindDn, credentials, mechanisms, saslAuthId);
}
Basically if the authentication fails the code would throw an
LdapAuthenticationException. This is working fine, the client will receive
an "Invalid credentials" (49). However, when the authentication succeeds I'm
not sure what to do here.
If the code just returns immediately, the client will receive an "Alias
problem" (33). If the code calls the next interceptor, ApacheDS will call
the lookup() method anonymously to get the userPassword attribute of the
user. Since my program won't return anything to unauthenticated users, this
operation will fail eventually with "Invalid credentials" (49).
What is the proper way to use Interceptor.bind()? Or is this a bug? I put my
interceptor in front of the other interceptors, is this a problem? Thank you
very much.
--
Endi S. Dewata
| |
| Norbet Reilly 2006-02-22, 5:45 pm |
| Hi,
You're one of the Penrose folks right? If so, I considered using your
solution except the licensing wasn't "open" enough for my corporate
masters :-(
I'm also using the new bind() call (in fact I sort of motivated it's
addition a while back) but have found I still needed a custom
authenticator. I thought I'd delay discussing this until RC1 is out
the door - but since you brought it up.
Currently the code only falls back to using the custom partition's
bind when presented with an unknown authentication mechanism (refer
org.apache.directory.server.core.authn.AuthenticationService.bind()),
which isn't that useful for implementors of custom (proxy) partitions
wanting to delegate their binds.
To add more useful semantics one needs to distinguish between two cases:
1. bind DN falls inside custom partition but it doesn't implement
bind, in this case I throw javax.naming.OperationNotSupportedException
(I have made throwing this exception the default bind() implementation
in org.apache.directory.server.core.partition.AbstractDirectoryPartition.bi=
nd())
2. bind DN falls inside custom partition but when it's bind()
method is invoked the provided credentials are not valid or the
required auth mechanism is not supported, in this case
org.apache.directory.shared.ldap.exception.LdapAuthenticationException
or org.apache.directory.shared.ldap.exception.LdapAuthenticationNotSupporte=
dException
are thrown).
The current AD code doesn't single out case 1.
I have some patches I'm using to support the bind stuff in a more
custom-partition-friendly way, if you (or the list) is interested. I
also have a patch for dynamically reading schemas from custom
partitions and combining them with the static schemas read by AD at
start-up.
| |
| Endi S. Dewata 2006-02-25, 5:45 pm |
| Hi Norbet,
Thanks for replying.
> You're one of the Penrose folks right? If so, I considered using your
> solution except the licensing wasn't "open" enough for my corporate
> masters :-(
Too bad... but if you'd like to discuss Penrose issues please feel free
contact me directly.
> I'm also using the new bind() call (in fact I sort of motivated it's
> addition a while back) but have found I still needed a custom
> authenticator. I thought I'd delay discussing this until RC1 is out
> the door - but since you brought it up.
> Currently the code only falls back to using the custom partition's
> bind when presented with an unknown authentication mechanism (refer
> org.apache.directory.server.core.authn.AuthenticationService.bind()),
> which isn't that useful for implementors of custom (proxy) partitions
> wanting to delegate their binds.
Unfortunately this won't work for me because I need to authenticate users
coming in using a known mechanism (e.g. simple). What if the code is changed
such that it calls the next interceptor's bind() method after exhausting all
available authenticators? I think it would be more useful.
Thanks!
--
Endi S. Dewata
|
|
|
|
|