Re: LDAP Triggers use cases: Need for real world data

[Enrique Rodriguez <en...@gmail.com>]

Ersin Er wrote:
> Enrique Rodriguez wrote:
>> Ersin Er wrote:
...
> So the Change Password Protocol provider is currently able to do this
> generation/conversion but the Core and LDAP Protocol Provider are not
> aware of this, right?

Correct.  Change Password protocol provider can also enforce password 
policy (minimum length, character mix, etc.) which at some point should 
be enforced globally.

...
> OK, so we'll have Triggers for modification type operations for the
> ou=Users based subtree. Is it reasonable to do this with an AFTER
> Trigger so that the Kerberos related attributes will be updated just
> after the entry has been added/modified? Because I'm not sure whether
> we'll support modification of request parameters inside triggered stored
> procedures.

I think this makes sense.

...
>> By using triggers we can address this need server-side, and not
>> require any custom client side logic to derive keys from passwords. 
>> This will make the use of Apache Directory with Kerberos much easier.
> More hints are welcome ;-) We may also have an IRC session on
> implementing this. I'll finish the preliminary version of triggers for
> playing with in a few days.

I am really looking forward to this.  This is going to make working with 
Kerberos way more user-friendly.

Enrique

Re: LDAP Triggers use cases: Need for real world data

[Ersin Er <er...@gmail.com>]

On 7/16/06, Ersin Er <er...@gmail.com> wrote:
> Hi Emmanuel,

s/Emmanuel/Enrique. Sorry :-)

> Thanks for the responses.
>
> More to say inlined..
>
> On 7/16/06, Enrique Rodriguez <en...@gmail.com> wrote:
> > Ersin Er wrote:
> > > On 7/15/06, Enrique Rodriguez <en...@gmail.com> wrote:
> > >> Ersin Er wrote:
> > >> > Enrique Rodriguez wrote:
> > >> >> Ersin Er wrote:
> > >> ...
> > >> > So the Change Password Protocol provider is currently able to do this
> > >> > generation/conversion but the Core and LDAP Protocol Provider are not
> > >> > aware of this, right?
> > >>
> > >> Correct.  Change Password protocol provider can also enforce password
> > >> policy (minimum length, character mix, etc.) which at some point should
> > >> be enforced globally.
> > >
> > > One more question: Change Password Protocol does not use clear text
> > > passwords, right? So we'll never be able to keep LDAP and Kerberos
> > > passwords in sync, right?
> >
> > The user enters a plaintext password on the client and that plaintext
> > password does traverse the network.  The server-side will have the
> > plaintext password.  So, I think that the answers to your questions are:
> >   Change Password does "use" clear text passwords.  We will be able to
> > keep LDAP and Kerberos passwords in sync.
>
> So where does the conversion occurs from clear text to KerberosKey
> object. (I could learn this via a constructor usage search but I do
> not have an environment here.)
>
> BTW, SP and Triggers are core level constructs. So I do not think that
> the clear text password reachs the core. But it's also a fact that
> Kerberos service itself can update LDAP password to keep both
> passwords in sync. So, adding an 'userPassword' update inside the
> Kerberos service's operation chain should not be hard.
>
> > While a plaintext password does traverse the network, it is over a
> > secure channel set up by the Change Password protocol in conjunction
> > with the Kerberos protocol.
> >
> > >
> > >> ...
> > >> > OK, so we'll have Triggers for modification type operations for the
> > >> > ou=Users based subtree. Is it reasonable to do this with an AFTER
> > >> > Trigger so that the Kerberos related attributes will be updated just
> > >> > after the entry has been added/modified? Because I'm not sure whether
> > >> > we'll support modification of request parameters inside triggered
> > >> stored
> > >> > procedures.
> > >>
> > >> I think this makes sense.
> > >
> > > Well, I have futher investigated this and saw that Kerberos related
> > > object class does not require the password related attribute to exist
> > > mandatorily. So it's ok to have an object class for Kerberos and not
> > > having the password attribute and adding the password attribute with
> > > another operation. So there is no pb here.
> >
> > OK, I see what you're saying.  In fact, one of the major enhancements to
> > the 2nd version of Change Password was to add the ability to initialize
> > the password for a new user, from the client-side.
> >
> > Enrique
> >
> >
>
>
> --
> Ersin
>


-- 
Ersin

Re: LDAP Triggers use cases: Need for real world data

[Enrique Rodriguez <en...@gmail.com>]

Ersin Er wrote:
...
> So where does the conversion occurs from clear text to KerberosKey
> object. (I could learn this via a constructor usage search but I do
> not have an environment here.)
> 
> BTW, SP and Triggers are core level constructs. So I do not think that
> the clear text password reachs the core. But it's also a fact that
> Kerberos service itself can update LDAP password to keep both
> passwords in sync. So, adding an 'userPassword' update inside the
> Kerberos service's operation chain should not be hard.
...

The Change Password Protocol is comprised of a single Chain of 
Responsibility using a MINA IoHandlerChain called the 
ChangePasswordChain.  In the ChangePasswordChain is an IoHandlerCommand 
"link" called ProcessPasswordChange.  In ProcessPasswordChange the 
plaintext password is converted to a KerberosKey and stored in the DIT.

So, you are correct that currently the plaintext password does not reach 
the core.  What I'm picturing is that 4 things change:

1)  The Change Password protocol simply passes the plaintext password to 
the core.

2)  The core handles the conversion of the plaintext password to 1..n 
key types.  Right now Change Password only creates a DES key and the 
intent was to not handle additional key types in the protocol provider, 
but rather to wait for triggers/SP's in the core to do the 1..n 
conversions based on configuration.

3)  Password policy enforcement also moves to the core, for reuse by 
other mechanisms for password changes.  Password policy is currently 
enforced in the CheckPasswordPolicy IoHandlerCommand.  There is a major 
issue here that rejected passwords would need to result in error 
handling that results in the proper Change Password error being returned 
to the client.

4)  Looking further down the road, yet relevant to your access control 
work, passwords should be modifiable according to access control.  Users 
need to be able to change their own password and, additionally, admins 
with proper rights need to be able to initialize and change passwords, too.

Enrique

Re: LDAP Triggers use cases: Need for real world data

[Ersin Er <er...@gmail.com>]

Hi Emmanuel,

Thanks for the responses.

More to say inlined..

On 7/16/06, Enrique Rodriguez <en...@gmail.com> wrote:
> Ersin Er wrote:
> > On 7/15/06, Enrique Rodriguez <en...@gmail.com> wrote:
> >> Ersin Er wrote:
> >> > Enrique Rodriguez wrote:
> >> >> Ersin Er wrote:
> >> ...
> >> > So the Change Password Protocol provider is currently able to do this
> >> > generation/conversion but the Core and LDAP Protocol Provider are not
> >> > aware of this, right?
> >>
> >> Correct.  Change Password protocol provider can also enforce password
> >> policy (minimum length, character mix, etc.) which at some point should
> >> be enforced globally.
> >
> > One more question: Change Password Protocol does not use clear text
> > passwords, right? So we'll never be able to keep LDAP and Kerberos
> > passwords in sync, right?
>
> The user enters a plaintext password on the client and that plaintext
> password does traverse the network.  The server-side will have the
> plaintext password.  So, I think that the answers to your questions are:
>   Change Password does "use" clear text passwords.  We will be able to
> keep LDAP and Kerberos passwords in sync.

So where does the conversion occurs from clear text to KerberosKey
object. (I could learn this via a constructor usage search but I do
not have an environment here.)

BTW, SP and Triggers are core level constructs. So I do not think that
the clear text password reachs the core. But it's also a fact that
Kerberos service itself can update LDAP password to keep both
passwords in sync. So, adding an 'userPassword' update inside the
Kerberos service's operation chain should not be hard.

> While a plaintext password does traverse the network, it is over a
> secure channel set up by the Change Password protocol in conjunction
> with the Kerberos protocol.
>
> >
> >> ...
> >> > OK, so we'll have Triggers for modification type operations for the
> >> > ou=Users based subtree. Is it reasonable to do this with an AFTER
> >> > Trigger so that the Kerberos related attributes will be updated just
> >> > after the entry has been added/modified? Because I'm not sure whether
> >> > we'll support modification of request parameters inside triggered
> >> stored
> >> > procedures.
> >>
> >> I think this makes sense.
> >
> > Well, I have futher investigated this and saw that Kerberos related
> > object class does not require the password related attribute to exist
> > mandatorily. So it's ok to have an object class for Kerberos and not
> > having the password attribute and adding the password attribute with
> > another operation. So there is no pb here.
>
> OK, I see what you're saying.  In fact, one of the major enhancements to
> the 2nd version of Change Password was to add the ability to initialize
> the password for a new user, from the client-side.
>
> Enrique
>
>


-- 
Ersin

Re: LDAP Triggers use cases: Need for real world data

[Enrique Rodriguez <en...@gmail.com>]

Ersin Er wrote:
> On 7/15/06, Enrique Rodriguez <en...@gmail.com> wrote:
>> Ersin Er wrote:
>> > Enrique Rodriguez wrote:
>> >> Ersin Er wrote:
>> ...
>> > So the Change Password Protocol provider is currently able to do this
>> > generation/conversion but the Core and LDAP Protocol Provider are not
>> > aware of this, right?
>>
>> Correct.  Change Password protocol provider can also enforce password
>> policy (minimum length, character mix, etc.) which at some point should
>> be enforced globally.
> 
> One more question: Change Password Protocol does not use clear text
> passwords, right? So we'll never be able to keep LDAP and Kerberos
> passwords in sync, right?

The user enters a plaintext password on the client and that plaintext 
password does traverse the network.  The server-side will have the 
plaintext password.  So, I think that the answers to your questions are: 
  Change Password does "use" clear text passwords.  We will be able to 
keep LDAP and Kerberos passwords in sync.

While a plaintext password does traverse the network, it is over a 
secure channel set up by the Change Password protocol in conjunction 
with the Kerberos protocol.

> 
>> ...
>> > OK, so we'll have Triggers for modification type operations for the
>> > ou=Users based subtree. Is it reasonable to do this with an AFTER
>> > Trigger so that the Kerberos related attributes will be updated just
>> > after the entry has been added/modified? Because I'm not sure whether
>> > we'll support modification of request parameters inside triggered 
>> stored
>> > procedures.
>>
>> I think this makes sense.
> 
> Well, I have futher investigated this and saw that Kerberos related
> object class does not require the password related attribute to exist
> mandatorily. So it's ok to have an object class for Kerberos and not
> having the password attribute and adding the password attribute with
> another operation. So there is no pb here.

OK, I see what you're saying.  In fact, one of the major enhancements to 
the 2nd version of Change Password was to add the ability to initialize 
the password for a new user, from the client-side.

Enrique

Re: LDAP Triggers use cases: Need for real world data

[Ersin Er <er...@gmail.com>]

On 7/15/06, Enrique Rodriguez <en...@gmail.com> wrote:
> Ersin Er wrote:
> > Enrique Rodriguez wrote:
> >> Ersin Er wrote:
> ...
> > So the Change Password Protocol provider is currently able to do this
> > generation/conversion but the Core and LDAP Protocol Provider are not
> > aware of this, right?
>
> Correct.  Change Password protocol provider can also enforce password
> policy (minimum length, character mix, etc.) which at some point should
> be enforced globally.

One more question: Change Password Protocol does not use clear text
passwords, right? So we'll never be able to keep LDAP and Kerberos
passwords in sync, right?

> ...
> > OK, so we'll have Triggers for modification type operations for the
> > ou=Users based subtree. Is it reasonable to do this with an AFTER
> > Trigger so that the Kerberos related attributes will be updated just
> > after the entry has been added/modified? Because I'm not sure whether
> > we'll support modification of request parameters inside triggered stored
> > procedures.
>
> I think this makes sense.

Well, I have futher investigated this and saw that Kerberos related
object class does not require the password related attribute to exist
mandatorily. So it's ok to have an object class for Kerberos and not
having the password attribute and adding the password attribute with
another operation. So there is no pb here.

> ...
> >> By using triggers we can address this need server-side, and not
> >> require any custom client side logic to derive keys from passwords.
> >> This will make the use of Apache Directory with Kerberos much easier.
> > More hints are welcome ;-) We may also have an IRC session on
> > implementing this. I'll finish the preliminary version of triggers for
> > playing with in a few days.
>
> I am really looking forward to this.  This is going to make working with
> Kerberos way more user-friendly.

I will complete it very soon. I'm a bit busy daily stuff. It will be
nice to provide some solution with our baby system. :)

> Enrique

-- 
Ersin