You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by vamsi krishna <vk...@gmail.com> on 2013/02/21 13:19:16 UTC
Extending Authentication for Bind
Hello All,
I am trying to extend Authentication from ApacheDS. I am trying to write a
Custom Authenticator that will
1. Take the username and password presented in the Bind, and lookup
Username and Passwords from a backend database (Oracle)
2. Authenticate the User and Password based on the database values
3. Accept the Bind.
So Far, I have been successful in Creating a Custom Authenticator that is
able to validate Username and Passwords from my backend Databases. However
once that is done my bind requests are failing with
*[17:31:34] ERROR
[org.apache.directory.server.core.authn.AbstractAuthenticator]*
*- ERR_6 Authentication error : ERR_268 Cannot find a partition for
uid=admin*
*
*
Exceptions on the Server Side.
Is there any help on how we can extend Authenticators in ApacheDS 2.0?
I have been trying to find resources but have been unsuccessful in doing
the same.
Thanks,
Vamsi
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 5:57 PM, vamsi krishna a écrit :
> What would be the best thing to do here, in this scenario?
>
> Will disabling PP be sufficient? Or writing a new ParititionInterceptor the
> right thing to do (I havent experimented this)?
Disable the PP.
I'll check to see if we can improve the way we handle delegated
authentication with respect to PP.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by vamsi krishna <vk...@gmail.com>.
What would be the best thing to do here, in this scenario?
Will disabling PP be sufficient? Or writing a new ParititionInterceptor the
right thing to do (I havent experimented this)?
On Thu, Feb 21, 2013 at 10:09 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> > don't think we have such a support right now do we? is that looping of
> > authenticators makes this a possibility?
>
> Yes, if we know that the user was authenticated by an external server.
> We may need to add a flag to know abut it.
>
> Should be easy to implement...
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> don't think we have such a support right now do we? is that looping of
> authenticators makes this a possibility?
Yes, if we know that the user was authenticated by an external server.
We may need to add a flag to know abut it.
Should be easy to implement...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Feb 22, 2013 at 5:51 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/22/13 12:34 PM, Kiran Ayyagari a écrit :
> > On Fri, Feb 22, 2013 at 3:08 PM, Emmanuel Lécharny <elecharny@gmail.com
> >wrote:
> >
> >> Le 2/22/13 9:11 AM, Kiran Ayyagari a écrit :
> >>> On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny <
> elecharny@gmail.com
> >>> wrote:
> >>>
> >>>> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
> >>>>> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <
> >> elecharny@gmail.com
> >>>>> wrote:
> >>>>>
> >>>>>> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> >>>>>>> don't think we have such a support right now do we? is that looping
> >> of
> >>>>>>> authenticators makes this a possibility?
> >>>>>> I see that the Authenticator interface provide a checkPwdPolicy()
> >>>> method :
> >>>>>> /**
> >>>>>> * performs checks on the given entry based on the specified
> >>>>>> password policy configuration
> >>>>>> *
> >>>>>> * @param userEntry the user entry to be checked for
> >> authentication
> >>>>>> * @throws PasswordPolicyException
> >>>>>> */
> >>>>>> void checkPwdPolicy( Entry userEntry ) throws LdapException;
> >>>>>>
> >>>>>> Why can't we do all the passwordPolicy checks in the authenticator,
> >>>>>> instead of the interceptor ?
> >>>>>>
> >>>>>> The only pb is that we need the user entry at this point, but
> couldn't
> >>>>>> we pass the BindContext, so for the checkPwdPolicy() to fetch the
> >> entry
> >>>>>> from the DS instead ?
> >>>>>>
> >>>>>> Does it make sense ?
> >>>>>>
> >>>>>> password policy is enforced not only during authentication but also
> >>>> after
> >>>>> authentication and while doing modify operation
> >>>> Absolutly, but here, I'm just mentioning the check when doing a bind.
> >>>> Every other operation should be done in the interceptors.
> >>>>
> >>>> we still need to perform several checkes during and after
> authentication
> >>> in the same bind operation
> >>> so we cannot move this logic entirely to authenticators
> >>>
> >> The thing is that we may not need the entry to do those checks. If we
> >> do, then it's a problem, because that means we can't delegate
> >> authentication...
> >>
> >> no we can bypass this by overriding the checkPwdPolicy() method (the
> > DelegatingAuthenticator does just that)
>
> It's sadly not enbough. In the AutenticationInterceptor.bind() method,
> we do :
>
> Dn dn = bindContext.getDn();
> Entry userEntry = bindContext.getEntry();
>
> PasswordPolicyConfiguration policyConfig = getPwdPolicy(
> userEntry );
>
> and the getPwdPolicy() method does :
>
> public PasswordPolicyConfiguration getPwdPolicy( Entry userEntry )
> throws LdapException
> {
> if ( pwdPolicyContainer == null )
> {
> return null;
> }
>
> if ( pwdPolicyContainer.hasCustomConfigs() )
> {
> Attribute pwdPolicySubentry = userEntry.get(
> pwdPolicySubentryAT );
>
> if ( pwdPolicySubentry != null )
> {
> Dn configDn =
> adminSession.getDirectoryService().getDnFactory().create(
> pwdPolicySubentry.getString() );
>
> return pwdPolicyContainer.getPolicyConfig( configDn );
> }
> }
>
> return pwdPolicyContainer.getDefaultPolicy();
> }
>
>
> So here, you'll get a NPE if the pwdPolicyContainer as some custom config.
>
> Attribute pwdPolicySubentry = userEntry.get(
> pwdPolicySubentryAT ); // usrEntry is null
>
> But we can fix that easily.
>
> My point is that the next code :
>
> if ( policyConfig != null )
> {
> LookupOperationContext lookupContext = new
> LookupOperationContext( adminSession, bindContext.getDn(),
> SchemaConstants.ALL_ATTRIBUTES_ARRAY );
> userEntry = directoryService.getPartitionNexus().lookup(
> lookupContext );
> }
>
> is useless if we have a delegated authentication : why should we lookup
> for the user entry when we know it's not present ?
>
>
> Well, so to speak, it will work, but it might worth some improvement, IMO.
>
> wdyt ?
>
>
> yes, we need a flag to bypass this
>
>
>
> >
> >> So we have to find a way to avoid requesting the entry.
> >>
> >> What are the checks we need to do btw ? (I've not spent much time on
> >> this part of the code...)
> >>
> >> it does password expiration, grace logins, locking/unlocking and checks
> > if the password is ready for use based on the activation time
>
> Such checks can't be done if the user is external, no ?
>
> yes, just mentioned what the code in authenticator does
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/22/13 12:34 PM, Kiran Ayyagari a écrit :
> On Fri, Feb 22, 2013 at 3:08 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Le 2/22/13 9:11 AM, Kiran Ayyagari a écrit :
>>> On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny <elecharny@gmail.com
>>> wrote:
>>>
>>>> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
>>>>> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <
>> elecharny@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
>>>>>>> don't think we have such a support right now do we? is that looping
>> of
>>>>>>> authenticators makes this a possibility?
>>>>>> I see that the Authenticator interface provide a checkPwdPolicy()
>>>> method :
>>>>>> /**
>>>>>> * performs checks on the given entry based on the specified
>>>>>> password policy configuration
>>>>>> *
>>>>>> * @param userEntry the user entry to be checked for
>> authentication
>>>>>> * @throws PasswordPolicyException
>>>>>> */
>>>>>> void checkPwdPolicy( Entry userEntry ) throws LdapException;
>>>>>>
>>>>>> Why can't we do all the passwordPolicy checks in the authenticator,
>>>>>> instead of the interceptor ?
>>>>>>
>>>>>> The only pb is that we need the user entry at this point, but couldn't
>>>>>> we pass the BindContext, so for the checkPwdPolicy() to fetch the
>> entry
>>>>>> from the DS instead ?
>>>>>>
>>>>>> Does it make sense ?
>>>>>>
>>>>>> password policy is enforced not only during authentication but also
>>>> after
>>>>> authentication and while doing modify operation
>>>> Absolutly, but here, I'm just mentioning the check when doing a bind.
>>>> Every other operation should be done in the interceptors.
>>>>
>>>> we still need to perform several checkes during and after authentication
>>> in the same bind operation
>>> so we cannot move this logic entirely to authenticators
>>>
>> The thing is that we may not need the entry to do those checks. If we
>> do, then it's a problem, because that means we can't delegate
>> authentication...
>>
>> no we can bypass this by overriding the checkPwdPolicy() method (the
> DelegatingAuthenticator does just that)
It's sadly not enbough. In the AutenticationInterceptor.bind() method,
we do :
Dn dn = bindContext.getDn();
Entry userEntry = bindContext.getEntry();
PasswordPolicyConfiguration policyConfig = getPwdPolicy(
userEntry );
and the getPwdPolicy() method does :
public PasswordPolicyConfiguration getPwdPolicy( Entry userEntry )
throws LdapException
{
if ( pwdPolicyContainer == null )
{
return null;
}
if ( pwdPolicyContainer.hasCustomConfigs() )
{
Attribute pwdPolicySubentry = userEntry.get(
pwdPolicySubentryAT );
if ( pwdPolicySubentry != null )
{
Dn configDn =
adminSession.getDirectoryService().getDnFactory().create(
pwdPolicySubentry.getString() );
return pwdPolicyContainer.getPolicyConfig( configDn );
}
}
return pwdPolicyContainer.getDefaultPolicy();
}
So here, you'll get a NPE if the pwdPolicyContainer as some custom config.
Attribute pwdPolicySubentry = userEntry.get(
pwdPolicySubentryAT ); // usrEntry is null
But we can fix that easily.
My point is that the next code :
if ( policyConfig != null )
{
LookupOperationContext lookupContext = new
LookupOperationContext( adminSession, bindContext.getDn(),
SchemaConstants.ALL_ATTRIBUTES_ARRAY );
userEntry = directoryService.getPartitionNexus().lookup(
lookupContext );
}
is useless if we have a delegated authentication : why should we lookup
for the user entry when we know it's not present ?
Well, so to speak, it will work, but it might worth some improvement, IMO.
wdyt ?
>
>> So we have to find a way to avoid requesting the entry.
>>
>> What are the checks we need to do btw ? (I've not spent much time on
>> this part of the code...)
>>
>> it does password expiration, grace logins, locking/unlocking and checks
> if the password is ready for use based on the activation time
Such checks can't be done if the user is external, no ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Feb 22, 2013 at 3:08 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/22/13 9:11 AM, Kiran Ayyagari a écrit :
> > On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny <elecharny@gmail.com
> >wrote:
> >
> >> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
> >>> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <
> elecharny@gmail.com
> >>> wrote:
> >>>
> >>>> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> >>>>> don't think we have such a support right now do we? is that looping
> of
> >>>>> authenticators makes this a possibility?
> >>>> I see that the Authenticator interface provide a checkPwdPolicy()
> >> method :
> >>>> /**
> >>>> * performs checks on the given entry based on the specified
> >>>> password policy configuration
> >>>> *
> >>>> * @param userEntry the user entry to be checked for
> authentication
> >>>> * @throws PasswordPolicyException
> >>>> */
> >>>> void checkPwdPolicy( Entry userEntry ) throws LdapException;
> >>>>
> >>>> Why can't we do all the passwordPolicy checks in the authenticator,
> >>>> instead of the interceptor ?
> >>>>
> >>>> The only pb is that we need the user entry at this point, but couldn't
> >>>> we pass the BindContext, so for the checkPwdPolicy() to fetch the
> entry
> >>>> from the DS instead ?
> >>>>
> >>>> Does it make sense ?
> >>>>
> >>>> password policy is enforced not only during authentication but also
> >> after
> >>> authentication and while doing modify operation
> >> Absolutly, but here, I'm just mentioning the check when doing a bind.
> >> Every other operation should be done in the interceptors.
> >>
> >> we still need to perform several checkes during and after authentication
> > in the same bind operation
> > so we cannot move this logic entirely to authenticators
> >
>
> The thing is that we may not need the entry to do those checks. If we
> do, then it's a problem, because that means we can't delegate
> authentication...
>
> no we can bypass this by overriding the checkPwdPolicy() method (the
DelegatingAuthenticator does just that)
> So we have to find a way to avoid requesting the entry.
>
> What are the checks we need to do btw ? (I've not spent much time on
> this part of the code...)
>
> it does password expiration, grace logins, locking/unlocking and checks
if the password is ready for use based on the activation time
> Thanks !
>
> PS : Moving this discussion to the dev mailing list
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/22/13 9:11 AM, Kiran Ayyagari a écrit :
> On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
>>> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <elecharny@gmail.com
>>> wrote:
>>>
>>>> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
>>>>> don't think we have such a support right now do we? is that looping of
>>>>> authenticators makes this a possibility?
>>>> I see that the Authenticator interface provide a checkPwdPolicy()
>> method :
>>>> /**
>>>> * performs checks on the given entry based on the specified
>>>> password policy configuration
>>>> *
>>>> * @param userEntry the user entry to be checked for authentication
>>>> * @throws PasswordPolicyException
>>>> */
>>>> void checkPwdPolicy( Entry userEntry ) throws LdapException;
>>>>
>>>> Why can't we do all the passwordPolicy checks in the authenticator,
>>>> instead of the interceptor ?
>>>>
>>>> The only pb is that we need the user entry at this point, but couldn't
>>>> we pass the BindContext, so for the checkPwdPolicy() to fetch the entry
>>>> from the DS instead ?
>>>>
>>>> Does it make sense ?
>>>>
>>>> password policy is enforced not only during authentication but also
>> after
>>> authentication and while doing modify operation
>> Absolutly, but here, I'm just mentioning the check when doing a bind.
>> Every other operation should be done in the interceptors.
>>
>> we still need to perform several checkes during and after authentication
> in the same bind operation
> so we cannot move this logic entirely to authenticators
>
The thing is that we may not need the entry to do those checks. If we
do, then it's a problem, because that means we can't delegate
authentication...
So we have to find a way to avoid requesting the entry.
What are the checks we need to do btw ? (I've not spent much time on
this part of the code...)
Thanks !
PS : Moving this discussion to the dev mailing list
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
> > On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <elecharny@gmail.com
> >wrote:
> >
> >> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> >>> don't think we have such a support right now do we? is that looping of
> >>> authenticators makes this a possibility?
> >> I see that the Authenticator interface provide a checkPwdPolicy()
> method :
> >>
> >> /**
> >> * performs checks on the given entry based on the specified
> >> password policy configuration
> >> *
> >> * @param userEntry the user entry to be checked for authentication
> >> * @throws PasswordPolicyException
> >> */
> >> void checkPwdPolicy( Entry userEntry ) throws LdapException;
> >>
> >> Why can't we do all the passwordPolicy checks in the authenticator,
> >> instead of the interceptor ?
> >>
> >> The only pb is that we need the user entry at this point, but couldn't
> >> we pass the BindContext, so for the checkPwdPolicy() to fetch the entry
> >> from the DS instead ?
> >>
> >> Does it make sense ?
> >>
> >> password policy is enforced not only during authentication but also
> after
> > authentication and while doing modify operation
>
> Absolutly, but here, I'm just mentioning the check when doing a bind.
> Every other operation should be done in the interceptors.
>
> we still need to perform several checkes during and after authentication
in the same bind operation
so we cannot move this logic entirely to authenticators
> Btw, I'm mocing the PPolicy test which is in core-integ into
> server-integ, as it requires a LdapNetworkConnection, and not a
> LdapCoreSessionConnection.
>
> +1
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
>>> don't think we have such a support right now do we? is that looping of
>>> authenticators makes this a possibility?
>> I see that the Authenticator interface provide a checkPwdPolicy() method :
>>
>> /**
>> * performs checks on the given entry based on the specified
>> password policy configuration
>> *
>> * @param userEntry the user entry to be checked for authentication
>> * @throws PasswordPolicyException
>> */
>> void checkPwdPolicy( Entry userEntry ) throws LdapException;
>>
>> Why can't we do all the passwordPolicy checks in the authenticator,
>> instead of the interceptor ?
>>
>> The only pb is that we need the user entry at this point, but couldn't
>> we pass the BindContext, so for the checkPwdPolicy() to fetch the entry
>> from the DS instead ?
>>
>> Does it make sense ?
>>
>> password policy is enforced not only during authentication but also after
> authentication and while doing modify operation
Absolutly, but here, I'm just mentioning the check when doing a bind.
Every other operation should be done in the interceptors.
Btw, I'm mocing the PPolicy test which is in core-integ into
server-integ, as it requires a LdapNetworkConnection, and not a
LdapCoreSessionConnection.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> > don't think we have such a support right now do we? is that looping of
> > authenticators makes this a possibility?
>
> I see that the Authenticator interface provide a checkPwdPolicy() method :
>
> /**
> * performs checks on the given entry based on the specified
> password policy configuration
> *
> * @param userEntry the user entry to be checked for authentication
> * @throws PasswordPolicyException
> */
> void checkPwdPolicy( Entry userEntry ) throws LdapException;
>
> Why can't we do all the passwordPolicy checks in the authenticator,
> instead of the interceptor ?
>
> The only pb is that we need the user entry at this point, but couldn't
> we pass the BindContext, so for the checkPwdPolicy() to fetch the entry
> from the DS instead ?
>
> Does it make sense ?
>
> password policy is enforced not only during authentication but also after
authentication and while doing modify operation
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit :
> don't think we have such a support right now do we? is that looping of
> authenticators makes this a possibility?
I see that the Authenticator interface provide a checkPwdPolicy() method :
/**
* performs checks on the given entry based on the specified
password policy configuration
*
* @param userEntry the user entry to be checked for authentication
* @throws PasswordPolicyException
*/
void checkPwdPolicy( Entry userEntry ) throws LdapException;
Why can't we do all the passwordPolicy checks in the authenticator,
instead of the interceptor ?
The only pb is that we need the user entry at this point, but couldn't
we pass the BindContext, so for the checkPwdPolicy() to fetch the entry
from the DS instead ?
Does it make sense ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
don't think we have such a support right now do we? is that looping of
authenticators makes this a possibility?
On Thu, Feb 21, 2013 at 9:53 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/21/13 5:21 PM, Kiran Ayyagari a écrit :
> > I prefer the admin to disable password policy rather than forcing it in
> the
> > server
>
> What if we decide to delegate half of the authent to an external server,
> and half is still controled locally with PP ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 5:21 PM, Kiran Ayyagari a écrit :
> I prefer the admin to disable password policy rather than forcing it in the
> server
What if we decide to delegate half of the authent to an external server,
and half is still controled locally with PP ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
I prefer the admin to disable password policy rather than forcing it in the
server
On Thu, Feb 21, 2013 at 9:49 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/21/13 5:15 PM, Kiran Ayyagari a écrit :
> > currently we assume(rightly so) that all the users will be in DS, however
> > providing a method to lookup(which a
> > custom authenticator can override) user will solve this issue
>
> Or we can bypass the PasswordPolicy check if the user has been
> authenticated outside of the server...
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 5:15 PM, Kiran Ayyagari a écrit :
> currently we assume(rightly so) that all the users will be in DS, however
> providing a method to lookup(which a
> custom authenticator can override) user will solve this issue
Or we can bypass the PasswordPolicy check if the user has been
authenticated outside of the server...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by Kiran Ayyagari <ka...@apache.org>.
currently we assume(rightly so) that all the users will be in DS, however
providing a method to lookup(which a
custom authenticator can override) user will solve this issue
On Thu, Feb 21, 2013 at 9:38 PM, vamsi krishna <vk...@gmail.com> wrote:
> I am running a debugger via Eclipse and can see that my authenticator was
> indeed called. After the authenticator has returned the Principal the Code
> is failing in the following line
>
> userEntry = directoryService.getPartitionNexus().lookup(
> lookupContext );
>
> Since I have custom Constructed the Principal, I am sure My user entry
> cannot be looked up. How do I get around this error? Do I have to now write
> a PartitionInterceptor to simulate Users not present in Ldap?
>
> Thanks,
> Vamsi
>
>
> On Thu, Feb 21, 2013 at 6:30 PM, Emmanuel Lécharny <elecharny@gmail.com
> >wrote:
>
> > Le 2/21/13 1:19 PM, vamsi krishna a écrit :
> > > Hello All,
> > >
> > > I am trying to extend Authentication from ApacheDS. I am trying to
> write
> > a
> > > Custom Authenticator that will
> > >
> > > 1. Take the username and password presented in the Bind, and lookup
> > > Username and Passwords from a backend database (Oracle)
> > > 2. Authenticate the User and Password based on the database values
> > > 3. Accept the Bind.
> > >
> > > So Far, I have been successful in Creating a Custom Authenticator that
> is
> > > able to validate Username and Passwords from my backend Databases.
> > However
> > > once that is done my bind requests are failing with
> > > *[17:31:34] ERROR
> > > [org.apache.directory.server.core.authn.AbstractAuthenticator]*
> > > *- ERR_6 Authentication error : ERR_268 Cannot find a partition for
> > > uid=admin*
> >
> > It's very likely that your authenticator is never actually called.
> >
> > You should add the specific Authenticator to the list of authenticators
> > associated with your authentication level (which can be simple, string
> > or anonymous. In your case, I suggest simple).
> >
> > Are you sure your authenticator is initialized ?
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> >
>
--
Kiran Ayyagari
http://keydap.com
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 5:08 PM, vamsi krishna a écrit :
> I am running a debugger via Eclipse and can see that my authenticator was
> indeed called. After the authenticator has returned the Principal the Code
> is failing in the following line
>
> userEntry = directoryService.getPartitionNexus().lookup(
> lookupContext );
>
> Since I have custom Constructed the Principal, I am sure My user entry
> cannot be looked up. How do I get around this error? Do I have to now write
> a PartitionInterceptor to simulate Users not present in Ldap?
You have enabled the PasswordPolicy module, I guess...
Do you need it ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Extending Authentication for Bind
Posted by vamsi krishna <vk...@gmail.com>.
I am running a debugger via Eclipse and can see that my authenticator was
indeed called. After the authenticator has returned the Principal the Code
is failing in the following line
userEntry = directoryService.getPartitionNexus().lookup(
lookupContext );
Since I have custom Constructed the Principal, I am sure My user entry
cannot be looked up. How do I get around this error? Do I have to now write
a PartitionInterceptor to simulate Users not present in Ldap?
Thanks,
Vamsi
On Thu, Feb 21, 2013 at 6:30 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/21/13 1:19 PM, vamsi krishna a écrit :
> > Hello All,
> >
> > I am trying to extend Authentication from ApacheDS. I am trying to write
> a
> > Custom Authenticator that will
> >
> > 1. Take the username and password presented in the Bind, and lookup
> > Username and Passwords from a backend database (Oracle)
> > 2. Authenticate the User and Password based on the database values
> > 3. Accept the Bind.
> >
> > So Far, I have been successful in Creating a Custom Authenticator that is
> > able to validate Username and Passwords from my backend Databases.
> However
> > once that is done my bind requests are failing with
> > *[17:31:34] ERROR
> > [org.apache.directory.server.core.authn.AbstractAuthenticator]*
> > *- ERR_6 Authentication error : ERR_268 Cannot find a partition for
> > uid=admin*
>
> It's very likely that your authenticator is never actually called.
>
> You should add the specific Authenticator to the list of authenticators
> associated with your authentication level (which can be simple, string
> or anonymous. In your case, I suggest simple).
>
> Are you sure your authenticator is initialized ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: Extending Authentication for Bind
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/21/13 1:19 PM, vamsi krishna a écrit :
> Hello All,
>
> I am trying to extend Authentication from ApacheDS. I am trying to write a
> Custom Authenticator that will
>
> 1. Take the username and password presented in the Bind, and lookup
> Username and Passwords from a backend database (Oracle)
> 2. Authenticate the User and Password based on the database values
> 3. Accept the Bind.
>
> So Far, I have been successful in Creating a Custom Authenticator that is
> able to validate Username and Passwords from my backend Databases. However
> once that is done my bind requests are failing with
> *[17:31:34] ERROR
> [org.apache.directory.server.core.authn.AbstractAuthenticator]*
> *- ERR_6 Authentication error : ERR_268 Cannot find a partition for
> uid=admin*
It's very likely that your authenticator is never actually called.
You should add the specific Authenticator to the list of authenticators
associated with your authentication level (which can be simple, string
or anonymous. In your case, I suggest simple).
Are you sure your authenticator is initialized ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com