[Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Dev,

I'm currently starting to work on the new ApacheDS Configuration Editor for the upcoming Apache DS 2.0.

Instead of taking the (dead and removed in ApacheDS 2.0) 'server.xml' it used to take in previous versions of Apache DS, this editor is now intended to read the 'Configuration Partition' of the new ApacheDS 2.0 version.
The idea is to be able to edit (read and write) the configuration from the 'config.ldif' file on disk, but also from a running ApacheDS via LDAP operations (under the 'ou=config' partition).

I'd like to propose some ideas around the design of the UI for the editor, and to have your thoughts about them, in order to make it as usual as possible.

First, the new editor will inherit a lot of things from the current one. Especially, its layout, with a tab based editor.

After a look at the current configuration partition implementation, here are the tabs I have identified:
- Overview
- LDAP(S) Server
- Kerberos Server
- Partitions
- Password Policy
- Replication
- Options

I excluded the configuration of the Interceptor Chain on purpose. I really think that it's an internal configuration the end-users should not be dealing with, but that can be inferred from the other configuration. Like, for example, if the Kerberos Server is enabled, we know that the KeyDerivation interceptor must be added to the interceptor chain at a particular location in it, and the editor will do that for the user under the hood when the 'Enable Kerberos Server' button is pressed.

Same thing for Extended Operation Handlers.

At the moment, DNS, DHCP and NTP server configurations are excluded from the editor, given their current state in development and testing, as well as the value for our users to be able configure such servers (I'm not really they come to ApacheDS for this sets of features).


In the following paragraphs I'll go into more details for each individual tab:

-> Overview Tab
----------------------

This tab is intended to allow a quick access to the most essential and useful settings.
We'll have widgets to enable LDAP(S) or Kerberos Servers, as well as set their listening ports.
We would also have a recap of the most important settings in the other tabs, with the ability to jump to advanced configuration in each section.


-> LDAP(S) Server
-------------------------

This tab will be used to control the LDAP and LDAPS Servers settings.
Users should be able to enable/disable LDAP and LDAPS independently, as well as specifying their ports.
They should also be able to:
- enable/disable access control, anonymous access
- choose the supported authentication mechanisms
- set the SASL settings (host, principal, realms, etc)
- set the limits (time limit, size limit, etc)
- keystore, certificate (and when it's migrated to the configuration, the admin's credentials)


-> Kerberos Server
-------------------------

This tab will be used to control the Kerbros Server settings.
Users should be able to enable/disable Kerbros, as well as specifying its port.
The following AT values will also need to be edited via the UI:
- ads-krballowableclockskew
- ads-krbbodychecksumverified
- ads-krbemptyaddressesallowed
- ads-krbencryptiontypes
- ads-krbforwardableallowed
- ads-krbkdcprincipal
- ads-krbmaximumrenewablelifetime
- ads-krbmaximumticketlifetime
- ads-krbpaenctimestamprequired
- ads-krbpostdatedallowed
- ads-krbprimaryrealm
- ads-krbproxiableallowed
- ads-krbrenewableallowed
- ads-searchbasedn

I don't have a particular idea in mind yet on how these settings can be organized in the UI.
If you do, please let me know.


-> Partitions Tab
----------------------

This tab will reuse the existing Partitions Tab of previous editor versions.
It allows the creation, edition and deletion of partitions with their specific properties (ID, Cache Size, Suffix, Optimizer Enablement, Syncho On Write Enablement and creation, edition and deletion of Indexed Attributes).
An overview of the existing Partitions Tab can be seen at this URL:
http://directory.apache.org/studio/static/users_guide/apacheds_configuration/configuration_editor_1.5.5_partitions.html


-> Password Policy Tab
--------------------------------

This will be used to define all settings related to the password policy sub-system.
The user will be able to enable/disable it, and edit the following AT values via the UI:
- ads-pwdattribute
- ads-enabled: true
- ads-pwdallowuserchange
- ads-pwdcheckquality
- ads-pwdexpirewarning
- ads-pwdfailurecountinterval
- ads-pwdgraceauthnlimit
- ads-pwdinhistory
- ads-pwdlockout
- ads-pwdlockoutduration
- ads-pwdmaxage
- ads-pwdmaxfailure
- ads-pwdminage
- ads-pwdminlength
- ads-pwdmustchange
- ads-pwdsafemodify

Again, I need to see how these things could be regrouped and organized.
If you already have ideas.


-> Replication Tab
-------------------------

This tab will be used to define all settings related to the replication sub-system.
I'm waiting on you guys to tell me what and how replication should be configured.
I'm not even sure we have a working configuration for this already.


-> Options Tab
--------------------

This tab will be dedicated to more general and technical settings like:
- denormalization of operational attributes
- max PDU size
- synchronization period
- journal (location, filename, rotation)
- changelog
We could also put the configuration of the embedded HTTP server and webapps in there.


Thoughts?

Regards,
Pierre-Arnaud

Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Kiran,

On 4 nov. 2010, at 19:32, Kiran Ayyagari wrote:
> [SNIP]
>> 
> 
>>>> -> Overview Tab
>>>> ----------------------
>>>> 
>>>> This tab is intended to allow a quick access to the most essential and
>>>> useful settings.
>>>> We'll have widgets to enable LDAP(S) or Kerberos Servers, as well as set
>>>> their listening ports.
>>>> We would also have a recap of the most important settings in the other
>>>> tabs, with the ability to jump to advanced configuration in each section.
>>> 
>>> Do you think this should be a read-only overview panel? Otherwise some
>>> settings can be edited in two places, which might be confusing.
>> 
>> That's a good question. I didn't think having these particular settings
>> editable at multiple place could be a problem...
>> But, you're might be right, maybe we can/should make the overview tab just a
>> simple read-only tab.
>> Do others think it might lead to some confusion?
> hmm, is it possible to link them? (so that an action on these will be
> applied in their
> respective tabs)

Yeah, of course, that's how I was seeing it.

>>>> -> LDAP(S) Server
>>>> -------------------------
>>>> 
>>>> This tab will be used to control the LDAP and LDAPS Servers settings.
>>>> Users should be able to enable/disable LDAP and LDAPS independently, as
>>>> well as specifying their ports.
>>>> They should also be able to:
>>>> - enable/disable access control, anonymous access
>>> 
>>>> - choose the supported authentication mechanisms
>>>> - set the SASL settings (host, principal, realms, etc)
>>> Those are complicated settings, they depend on each other and other
>>> settings. For example CRAM-MD5 or DIGEST-MD5 don't work when the
>>> stored password is hashed (I don't know if that's a general limitation
>>> or only applied to ApacheDS).
>> 
>> Yeah, these are not very simple settings, but I think they need to appear in
>> the editor.
>> Would you prefer to hide them?
> one idea is to check if the XXXPasswordHashingInterceptor is enabled,
> if yes then these
> SASL mechanisms can't be enabled

Interesting, thanks for the info. :)

>> Actually, it seems the specs indicates that password should be stored as
>> plain text. I ran into this issue a few days ago when testing a CRAM-MD5
>> bind with the  new Apache Directory LDAP API within Studio.
>> Here's what Wikipedia indicates in the Protocol Weaknesses of the CRAM-MD5:
>> "Need to secure server: The server needs access to the users' plain text
>> passwords. Therefore it must take additional care to secure these passwords.
>> Typically by using reversable cryptography."
>> -> http://en.wikipedia.org/wiki/CRAM-MD5
>> 
>>> 
>>>> - set the limits (time limit, size limit, etc)
>>>> - keystore, certificate (and when it's migrated to the configuration, the
>>>> admin's credentials)
>>> 
>>> Some additional widgets:
>>> - enable/disable TLS
>>> - enable/disable server-side password hashing and select hashing method
>> 
>> I'm not sure we have configuration elements for these. But it would
>> definitely be something to have...
>> 
> yes, for TLS we have to unregister(do not add) the StartTlsHandler
> and for password hashing enable/disable XXXPasswordHashingInterceptor
> Note that there are not options as such like ads-disableTls (or
> ads-disablePwdHashing)
> but these options need to be on GUI which actually perform the above
> mentioned steps
> behind the scene

Agreed.

> [SNIP]
> 
>>>> -> Partitions Tab
>>>> ----------------------
>>>> 
>>>> This tab will reuse the existing Partitions Tab of previous editor
>>>> versions.
>>>> It allows the creation, edition and deletion of partitions with their
>>>> specific properties (ID, Cache Size, Suffix, Optimizer Enablement, Syncho
>>>> On Write Enablement and creation, edition and deletion of Indexed
>>>> Attributes).
>>>> An overview of the existing Partitions Tab can be seen at this URL:
>>>> http://directory.apache.org/studio/static/users_guide/apacheds_configuration/configuration_editor_1.5.5_partitions.html
>>> 
>>> Ok.
>>> 
>>> For the index attributes it would be nice to show the attribute name
>>> instead of the OID.
>> 
>> Yeah, we could also do if we an access the schema, or use a default schema
>> (in case we don't have access to the online schema).
>> 
>>> Maybe that widget should be splitted: system
>>> indexes (including objectClass and entryUUID) and user indexes
>> 
>> At the moment, I think we cannot differentiate system and user indexes. I'm
>> even wondering if the configuration shouldn't only contain user defined
>> indexes, system indexes being created automatically by the 'system'.
>> 
> we can differentiate them with a bit of extra logic, and I do agree
> with the idea of splitting
> them into system and user categories, that helps users (normal users
> don't tinker with
> 'system' unless they know what they are *really* doing)

100% agreed. As long as we can easily differentiate them in the configuration, I'm ok with that.

> [SNIP]

> 
>>>> -> Password Policy Tab
>>>> --------------------------------
>>>> 
>>>> This will be used to define all settings related to the password policy
>>>> sub-system.
>>>> The user will be able to enable/disable it, and edit the following AT
>>>> values via the UI:
>>>> - ads-pwdattribute
>>>> - ads-enabled: true
>>>> - ads-pwdallowuserchange
>>>> - ads-pwdcheckquality
>>>> - ads-pwdexpirewarning
>>>> - ads-pwdfailurecountinterval
>>>> - ads-pwdgraceauthnlimit
>>>> - ads-pwdinhistory
>>>> - ads-pwdlockout
>>>> - ads-pwdlockoutduration
>>>> - ads-pwdmaxage
>>>> - ads-pwdmaxfailure
>>>> - ads-pwdminage
>>>> - ads-pwdminlength
>>>> - ads-pwdmustchange
>>>> - ads-pwdsafemodify
>>>> 
>>>> Again, I need to see how these things could be regrouped and organized.
>>>> If you already have ideas.
> I would prefer to show all the properties, (there are a lot of
> interrelated properties so we need to do a lot of validations in UI to
> set it right, which the draft explains clearly)
> I can lend my hand in writing this logic to save sometime for you to
> read the draft :)

Cool, thanks.
I already went through it very quickly. Interesting stuff but it needs a very clear UI to be used efficiently.

>>>> -> Replication Tab
>>>> -------------------------
>>>> 
>>>> This tab will be used to define all settings related to the replication
>>>> sub-system.
>>>> I'm waiting on you guys to tell me what and how replication should be
>>>> configured.
>>>> I'm not even sure we have a working configuration for this already.
>>>> 
> we have all the related config options, again I can chime in if we
> have the mockup of UI

Yeah, I'll need your help here.

>>>> -> Options Tab
>>>> --------------------
>>>> 
>>>> This tab will be dedicated to more general and technical settings like:
>>>> - denormalization of operational attributes
>>>> - max PDU size
>>>> - synchronization period
>>>> - journal (location, filename, rotation)
>>>> - changelog
>>>> We could also put the configuration of the embedded HTTP server and
>>>> webapps in there.
>>> 
>>> Pretty much.
>>> 
> sounds good to me
>>> 
>>> Some more ideas:
>>> - Indicate when a restart of the server is required (always?)
>> 
>> I think for most (all?) of these settings, a restart will be required.
>> For configuration editor based on an LDAP Connection with a server, we could
>> even add a button which restarts the server remotely (via an extended
>> operation). But, it might not be trivial to do.
>> 
> yeah, it is not trivial and IMO something to be targeted for a version after 2.0

Yeah, +1. Just throwing ideas for the future. ;)

>>> - Backup/Restore the configuration to/from an LDIF.
>> 
>> You'd be able to save a configuration editor based on an LDAP Connection via
>> the 'Save As...' menu item, but you're right a dedicated area in the editor
>> for this is much better. Especially for the restore feature.
>> +1.
> hmm, can we make the location transparent to user instead of selecting
> a menu option?

Yeah, I was thinking at a double icon/action in the upper right corner of the editor (which will be visible on every page).
One icon for Backup and another one for Restore.


I created a new dedicated project in Studio's trunk where I will create all the UI first. Once we all agree on the design and the set of functionalities, we can work on bindings each UI element to the configuration beans.

Thanks,
Pierre-Arnaud

Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed

[Kiran Ayyagari <ka...@apache.org>]

On 11/4/10, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi Stefan,
>
> Thanks for adding your contribution to this collaborative "brainstorming".
> :)
>
> On 4 nov. 2010, at 17:09, Stefan Seelmann wrote:
>
>> Thanks Pierre-Arnaud for the detailed idea.
>>
>> On Thu, Nov 4, 2010 at 3:48 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net>
>> wrote:
>>> Hi Dev,
>>>
>>> I'm currently starting to work on the new ApacheDS Configuration Editor
>>> for the upcoming Apache DS 2.0.
great!
>>>
>>> Instead of taking the (dead and removed in ApacheDS 2.0) 'server.xml' it
>>> used to take in previous versions of Apache DS, this editor is now
>>> intended to read the 'Configuration Partition' of the new ApacheDS 2.0
>>> version.
>>> The idea is to be able to edit (read and write) the configuration from
>>> the 'config.ldif' file on disk, but also from a running ApacheDS via LDAP
>>> operations (under the 'ou=config' partition).
>>>
>>> I'd like to propose some ideas around the design of the UI for the
>>> editor, and to have your thoughts about them, in order to make it as
>>> usual as possible.
>>>
>>> First, the new editor will inherit a lot of things from the current one.
>>> Especially, its layout, with a tab based editor.
>>>
>>> After a look at the current configuration partition implementation, here
>>> are the tabs I have identified:
>>> - Overview
>>> - LDAP(S) Server
>>> - Kerberos Server
>>> - Partitions
>>> - Password Policy
>>> - Replication
>>> - Options
>>>
>>> I excluded the configuration of the Interceptor Chain on purpose. I
>>> really think that it's an internal configuration the end-users should not
>>> be dealing with, but that can be inferred from the other configuration.
>>> Like, for example, if the Kerberos Server is enabled, we know that the
>>> KeyDerivation interceptor must be added to the interceptor chain at a
>>> particular location in it, and the editor will do that for the user under
>>> the hood when the 'Enable Kerberos Server' button is pressed.
>>
>> +1
+1 too
>>
>>> Same thing for Extended Operation Handlers.
>>>
>>> At the moment, DNS, DHCP and NTP server configurations are excluded from
>>> the editor, given their current state in development and testing, as well
>>> as the value for our users to be able configure such servers (I'm not
>>> really they come to ApacheDS for this sets of features).
>>
>> +1
yeah no point in adding support for them atm
>>
>>
>>> -> Overview Tab
>>> ----------------------
>>>
>>> This tab is intended to allow a quick access to the most essential and
>>> useful settings.
>>> We'll have widgets to enable LDAP(S) or Kerberos Servers, as well as set
>>> their listening ports.
>>> We would also have a recap of the most important settings in the other
>>> tabs, with the ability to jump to advanced configuration in each section.
>>
>> Do you think this should be a read-only overview panel? Otherwise some
>> settings can be edited in two places, which might be confusing.
>
> That's a good question. I didn't think having these particular settings
> editable at multiple place could be a problem...
> But, you're might be right, maybe we can/should make the overview tab just a
> simple read-only tab.
> Do others think it might lead to some confusion?
hmm, is it possible to link them? (so that an action on these will be
applied in their
respective tabs)
>
>>> -> LDAP(S) Server
>>> -------------------------
>>>
>>> This tab will be used to control the LDAP and LDAPS Servers settings.
>>> Users should be able to enable/disable LDAP and LDAPS independently, as
>>> well as specifying their ports.
>>> They should also be able to:
>>> - enable/disable access control, anonymous access
>>
>>> - choose the supported authentication mechanisms
>>> - set the SASL settings (host, principal, realms, etc)
>> Those are complicated settings, they depend on each other and other
>> settings. For example CRAM-MD5 or DIGEST-MD5 don't work when the
>> stored password is hashed (I don't know if that's a general limitation
>> or only applied to ApacheDS).
>
> Yeah, these are not very simple settings, but I think they need to appear in
> the editor.
> Would you prefer to hide them?
one idea is to check if the XXXPasswordHashingInterceptor is enabled,
if yes then these
SASL mechanisms can't be enabled
>
> Actually, it seems the specs indicates that password should be stored as
> plain text. I ran into this issue a few days ago when testing a CRAM-MD5
> bind with the  new Apache Directory LDAP API within Studio.
> Here's what Wikipedia indicates in the Protocol Weaknesses of the CRAM-MD5:
> "Need to secure server: The server needs access to the users' plain text
> passwords. Therefore it must take additional care to secure these passwords.
> Typically by using reversable cryptography."
> -> http://en.wikipedia.org/wiki/CRAM-MD5
>
>>
>>> - set the limits (time limit, size limit, etc)
>>> - keystore, certificate (and when it's migrated to the configuration, the
>>> admin's credentials)
>>
>> Some additional widgets:
>> - enable/disable TLS
>> - enable/disable server-side password hashing and select hashing method
>
> I'm not sure we have configuration elements for these. But it would
> definitely be something to have...
>
yes, for TLS we have to unregister(do not add) the StartTlsHandler
and for password hashing enable/disable XXXPasswordHashingInterceptor
Note that there are not options as such like ads-disableTls (or
ads-disablePwdHashing)
but these options need to be on GUI which actually perform the above
mentioned steps
behind the scene
>>> -> Kerberos Server
>>> -------------------------
>>>
>>> This tab will be used to control the Kerbros Server settings.
>>> Users should be able to enable/disable Kerbros, as well as specifying its
>>> port.
>>> The following AT values will also need to be edited via the UI:
>>> - ads-krballowableclockskew
>>> - ads-krbbodychecksumverified
>>> - ads-krbemptyaddressesallowed
>>> - ads-krbencryptiontypes
>>> - ads-krbforwardableallowed
>>> - ads-krbkdcprincipal
>>> - ads-krbmaximumrenewablelifetime
>>> - ads-krbmaximumticketlifetime
>>> - ads-krbpaenctimestamprequired
>>> - ads-krbpostdatedallowed
>>> - ads-krbprimaryrealm
>>> - ads-krbproxiableallowed
>>> - ads-krbrenewableallowed
>>> - ads-searchbasedn
>>>
>>> I don't have a particular idea in mind yet on how these settings can be
>>> organized in the UI.
>>> If you do, please let me know.
>>
>> Me neither.
>>
>> Maybe we should have two sections:
>> - one containing the most important attributes
>>  - enable/disable
>>  - ports
>>  - ads-krbkdcprincipal
>>  - ads-krbprimaryrealm
>>  - ads-searchbasedn
>>  - ads-krbencryptiontypes
>> - another containing the advanced attributes
>
> Yeah, I had in mind something very similar.
>
>
>>> -> Partitions Tab
>>> ----------------------
>>>
>>> This tab will reuse the existing Partitions Tab of previous editor
>>> versions.
>>> It allows the creation, edition and deletion of partitions with their
>>> specific properties (ID, Cache Size, Suffix, Optimizer Enablement, Syncho
>>> On Write Enablement and creation, edition and deletion of Indexed
>>> Attributes).
>>> An overview of the existing Partitions Tab can be seen at this URL:
>>> http://directory.apache.org/studio/static/users_guide/apacheds_configuration/configuration_editor_1.5.5_partitions.html
>>
>> Ok.
>>
>> For the index attributes it would be nice to show the attribute name
>> instead of the OID.
>
> Yeah, we could also do if we an access the schema, or use a default schema
> (in case we don't have access to the online schema).
>
>> Maybe that widget should be splitted: system
>> indexes (including objectClass and entryUUID) and user indexes
>
> At the moment, I think we cannot differentiate system and user indexes. I'm
> even wondering if the configuration shouldn't only contain user defined
> indexes, system indexes being created automatically by the 'system'.
>
we can differentiate them with a bit of extra logic, and I do agree
with the idea of splitting
them into system and user categories, that helps users (normal users
don't tinker with
'system' unless they know what they are *really* doing)

>
>> And a new widget to define the context entry would be nice. And a
>> button to generate the context entry based on the suffix (dc, o, ou)
>
> Yeah, we had such a widget in previous versions of the editor, when the
> server configuration allowed it.
> +1 for the automatic generation button.
> Maybe, it could only just be a switch (true, false) and we can let the
> server generate it for us.
>
>>> -> Password Policy Tab
>>> --------------------------------
>>>
>>> This will be used to define all settings related to the password policy
>>> sub-system.
>>> The user will be able to enable/disable it, and edit the following AT
>>> values via the UI:
>>> - ads-pwdattribute
>>> - ads-enabled: true
>>> - ads-pwdallowuserchange
>>> - ads-pwdcheckquality
>>> - ads-pwdexpirewarning
>>> - ads-pwdfailurecountinterval
>>> - ads-pwdgraceauthnlimit
>>> - ads-pwdinhistory
>>> - ads-pwdlockout
>>> - ads-pwdlockoutduration
>>> - ads-pwdmaxage
>>> - ads-pwdmaxfailure
>>> - ads-pwdminage
>>> - ads-pwdminlength
>>> - ads-pwdmustchange
>>> - ads-pwdsafemodify
>>>
>>> Again, I need to see how these things could be regrouped and organized.
>>> If you already have ideas.
I would prefer to show all the properties, (there are a lot of
interrelated properties so we need to do a lot of validations in UI to
set it right, which the draft explains clearly)
I can lend my hand in writing this logic to save sometime for you to
read the draft :)
>>>
>>>
>>> -> Replication Tab
>>> -------------------------
>>>
>>> This tab will be used to define all settings related to the replication
>>> sub-system.
>>> I'm waiting on you guys to tell me what and how replication should be
>>> configured.
>>> I'm not even sure we have a working configuration for this already.
>>>
we have all the related config options, again I can chime in if we
have the mockup of UI
>>>
>>> -> Options Tab
>>> --------------------
>>>
>>> This tab will be dedicated to more general and technical settings like:
>>> - denormalization of operational attributes
>>> - max PDU size
>>> - synchronization period
>>> - journal (location, filename, rotation)
>>> - changelog
>>> We could also put the configuration of the embedded HTTP server and
>>> webapps in there.
>>
>> Pretty much.
>>
sounds good to me
>>
>> Some more ideas:
>> - Indicate when a restart of the server is required (always?)
>
> I think for most (all?) of these settings, a restart will be required.
> For configuration editor based on an LDAP Connection with a server, we could
> even add a button which restarts the server remotely (via an extended
> operation). But, it might not be trivial to do.
>
yeah, it is not trivial and IMO something to be targeted for a version after 2.0
>> - Backup/Restore the configuration to/from an LDIF.
>
> You'd be able to save a configuration editor based on an LDAP Connection via
> the 'Save As...' menu item, but you're right a dedicated area in the editor
> for this is much better. Especially for the restore feature.
> +1.
hmm, can we make the location transparent to user instead of selecting
a menu option?

thank you
-- 
Kiran Ayyagari

Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Stefan,

Thanks for adding your contribution to this collaborative "brainstorming". :)

On 4 nov. 2010, at 17:09, Stefan Seelmann wrote:

> Thanks Pierre-Arnaud for the detailed idea.
> 
> On Thu, Nov 4, 2010 at 3:48 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
>> Hi Dev,
>> 
>> I'm currently starting to work on the new ApacheDS Configuration Editor for the upcoming Apache DS 2.0.
>> 
>> Instead of taking the (dead and removed in ApacheDS 2.0) 'server.xml' it used to take in previous versions of Apache DS, this editor is now intended to read the 'Configuration Partition' of the new ApacheDS 2.0 version.
>> The idea is to be able to edit (read and write) the configuration from the 'config.ldif' file on disk, but also from a running ApacheDS via LDAP operations (under the 'ou=config' partition).
>> 
>> I'd like to propose some ideas around the design of the UI for the editor, and to have your thoughts about them, in order to make it as usual as possible.
>> 
>> First, the new editor will inherit a lot of things from the current one. Especially, its layout, with a tab based editor.
>> 
>> After a look at the current configuration partition implementation, here are the tabs I have identified:
>> - Overview
>> - LDAP(S) Server
>> - Kerberos Server
>> - Partitions
>> - Password Policy
>> - Replication
>> - Options
>> 
>> I excluded the configuration of the Interceptor Chain on purpose. I really think that it's an internal configuration the end-users should not be dealing with, but that can be inferred from the other configuration. Like, for example, if the Kerberos Server is enabled, we know that the KeyDerivation interceptor must be added to the interceptor chain at a particular location in it, and the editor will do that for the user under the hood when the 'Enable Kerberos Server' button is pressed.
> 
> +1
> 
>> Same thing for Extended Operation Handlers.
>> 
>> At the moment, DNS, DHCP and NTP server configurations are excluded from the editor, given their current state in development and testing, as well as the value for our users to be able configure such servers (I'm not really they come to ApacheDS for this sets of features).
> 
> +1
> 
> 
>> -> Overview Tab
>> ----------------------
>> 
>> This tab is intended to allow a quick access to the most essential and useful settings.
>> We'll have widgets to enable LDAP(S) or Kerberos Servers, as well as set their listening ports.
>> We would also have a recap of the most important settings in the other tabs, with the ability to jump to advanced configuration in each section.
> 
> Do you think this should be a read-only overview panel? Otherwise some
> settings can be edited in two places, which might be confusing.

That's a good question. I didn't think having these particular settings editable at multiple place could be a problem...
But, you're might be right, maybe we can/should make the overview tab just a simple read-only tab.
Do others think it might lead to some confusion?

>> -> LDAP(S) Server
>> -------------------------
>> 
>> This tab will be used to control the LDAP and LDAPS Servers settings.
>> Users should be able to enable/disable LDAP and LDAPS independently, as well as specifying their ports.
>> They should also be able to:
>> - enable/disable access control, anonymous access
> 
>> - choose the supported authentication mechanisms
>> - set the SASL settings (host, principal, realms, etc)
> Those are complicated settings, they depend on each other and other
> settings. For example CRAM-MD5 or DIGEST-MD5 don't work when the
> stored password is hashed (I don't know if that's a general limitation
> or only applied to ApacheDS).

Yeah, these are not very simple settings, but I think they need to appear in the editor.
Would you prefer to hide them?

Actually, it seems the specs indicates that password should be stored as plain text. I ran into this issue a few days ago when testing a CRAM-MD5 bind with the  new Apache Directory LDAP API within Studio.
Here's what Wikipedia indicates in the Protocol Weaknesses of the CRAM-MD5:
"Need to secure server: The server needs access to the users' plain text passwords. Therefore it must take additional care to secure these passwords. Typically by using reversable cryptography."
-> http://en.wikipedia.org/wiki/CRAM-MD5

> 
>> - set the limits (time limit, size limit, etc)
>> - keystore, certificate (and when it's migrated to the configuration, the admin's credentials)
> 
> Some additional widgets:
> - enable/disable TLS
> - enable/disable server-side password hashing and select hashing method

I'm not sure we have configuration elements for these. But it would definitely be something to have...

>> -> Kerberos Server
>> -------------------------
>> 
>> This tab will be used to control the Kerbros Server settings.
>> Users should be able to enable/disable Kerbros, as well as specifying its port.
>> The following AT values will also need to be edited via the UI:
>> - ads-krballowableclockskew
>> - ads-krbbodychecksumverified
>> - ads-krbemptyaddressesallowed
>> - ads-krbencryptiontypes
>> - ads-krbforwardableallowed
>> - ads-krbkdcprincipal
>> - ads-krbmaximumrenewablelifetime
>> - ads-krbmaximumticketlifetime
>> - ads-krbpaenctimestamprequired
>> - ads-krbpostdatedallowed
>> - ads-krbprimaryrealm
>> - ads-krbproxiableallowed
>> - ads-krbrenewableallowed
>> - ads-searchbasedn
>> 
>> I don't have a particular idea in mind yet on how these settings can be organized in the UI.
>> If you do, please let me know.
> 
> Me neither.
> 
> Maybe we should have two sections:
> - one containing the most important attributes
>  - enable/disable
>  - ports
>  - ads-krbkdcprincipal
>  - ads-krbprimaryrealm
>  - ads-searchbasedn
>  - ads-krbencryptiontypes
> - another containing the advanced attributes

Yeah, I had in mind something very similar.


>> -> Partitions Tab
>> ----------------------
>> 
>> This tab will reuse the existing Partitions Tab of previous editor versions.
>> It allows the creation, edition and deletion of partitions with their specific properties (ID, Cache Size, Suffix, Optimizer Enablement, Syncho On Write Enablement and creation, edition and deletion of Indexed Attributes).
>> An overview of the existing Partitions Tab can be seen at this URL:
>> http://directory.apache.org/studio/static/users_guide/apacheds_configuration/configuration_editor_1.5.5_partitions.html
> 
> Ok.
> 
> For the index attributes it would be nice to show the attribute name
> instead of the OID.

Yeah, we could also do if we an access the schema, or use a default schema (in case we don't have access to the online schema).

> Maybe that widget should be splitted: system
> indexes (including objectClass and entryUUID) and user indexes

At the moment, I think we cannot differentiate system and user indexes. I'm even wondering if the configuration shouldn't only contain user defined indexes, system indexes being created automatically by the 'system'.


> And a new widget to define the context entry would be nice. And a
> button to generate the context entry based on the suffix (dc, o, ou)

Yeah, we had such a widget in previous versions of the editor, when the server configuration allowed it.
+1 for the automatic generation button.
Maybe, it could only just be a switch (true, false) and we can let the server generate it for us.

>> -> Password Policy Tab
>> --------------------------------
>> 
>> This will be used to define all settings related to the password policy sub-system.
>> The user will be able to enable/disable it, and edit the following AT values via the UI:
>> - ads-pwdattribute
>> - ads-enabled: true
>> - ads-pwdallowuserchange
>> - ads-pwdcheckquality
>> - ads-pwdexpirewarning
>> - ads-pwdfailurecountinterval
>> - ads-pwdgraceauthnlimit
>> - ads-pwdinhistory
>> - ads-pwdlockout
>> - ads-pwdlockoutduration
>> - ads-pwdmaxage
>> - ads-pwdmaxfailure
>> - ads-pwdminage
>> - ads-pwdminlength
>> - ads-pwdmustchange
>> - ads-pwdsafemodify
>> 
>> Again, I need to see how these things could be regrouped and organized.
>> If you already have ideas.
>> 
>> 
>> -> Replication Tab
>> -------------------------
>> 
>> This tab will be used to define all settings related to the replication sub-system.
>> I'm waiting on you guys to tell me what and how replication should be configured.
>> I'm not even sure we have a working configuration for this already.
>> 
>> 
>> -> Options Tab
>> --------------------
>> 
>> This tab will be dedicated to more general and technical settings like:
>> - denormalization of operational attributes
>> - max PDU size
>> - synchronization period
>> - journal (location, filename, rotation)
>> - changelog
>> We could also put the configuration of the embedded HTTP server and webapps in there.
> 
> Pretty much.
> 
> 
> Some more ideas:
> - Indicate when a restart of the server is required (always?)

I think for most (all?) of these settings, a restart will be required.
For configuration editor based on an LDAP Connection with a server, we could even add a button which restarts the server remotely (via an extended operation). But, it might not be trivial to do.

> - Backup/Restore the configuration to/from an LDIF.

You'd be able to save a configuration editor based on an LDAP Connection via the 'Save As...' menu item, but you're right a dedicated area in the editor for this is much better. Especially for the restore feature.
+1.

Thanks!

Regards,
Pierre-Arnaud


> 
> 
> Thanks again.
> 
> Kind Regards,
> Stefan

Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed

[Stefan Seelmann <se...@apache.org>]

Thanks Pierre-Arnaud for the detailed idea.

On Thu, Nov 4, 2010 at 3:48 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi Dev,
>
> I'm currently starting to work on the new ApacheDS Configuration Editor for the upcoming Apache DS 2.0.
>
> Instead of taking the (dead and removed in ApacheDS 2.0) 'server.xml' it used to take in previous versions of Apache DS, this editor is now intended to read the 'Configuration Partition' of the new ApacheDS 2.0 version.
> The idea is to be able to edit (read and write) the configuration from the 'config.ldif' file on disk, but also from a running ApacheDS via LDAP operations (under the 'ou=config' partition).
>
> I'd like to propose some ideas around the design of the UI for the editor, and to have your thoughts about them, in order to make it as usual as possible.
>
> First, the new editor will inherit a lot of things from the current one. Especially, its layout, with a tab based editor.
>
> After a look at the current configuration partition implementation, here are the tabs I have identified:
> - Overview
> - LDAP(S) Server
> - Kerberos Server
> - Partitions
> - Password Policy
> - Replication
> - Options
>
> I excluded the configuration of the Interceptor Chain on purpose. I really think that it's an internal configuration the end-users should not be dealing with, but that can be inferred from the other configuration. Like, for example, if the Kerberos Server is enabled, we know that the KeyDerivation interceptor must be added to the interceptor chain at a particular location in it, and the editor will do that for the user under the hood when the 'Enable Kerberos Server' button is pressed.

+1

> Same thing for Extended Operation Handlers.
>
> At the moment, DNS, DHCP and NTP server configurations are excluded from the editor, given their current state in development and testing, as well as the value for our users to be able configure such servers (I'm not really they come to ApacheDS for this sets of features).

+1


> -> Overview Tab
> ----------------------
>
> This tab is intended to allow a quick access to the most essential and useful settings.
> We'll have widgets to enable LDAP(S) or Kerberos Servers, as well as set their listening ports.
> We would also have a recap of the most important settings in the other tabs, with the ability to jump to advanced configuration in each section.

Do you think this should be a read-only overview panel? Otherwise some
settings can be edited in two places, which might be confusing.


> -> LDAP(S) Server
> -------------------------
>
> This tab will be used to control the LDAP and LDAPS Servers settings.
> Users should be able to enable/disable LDAP and LDAPS independently, as well as specifying their ports.
> They should also be able to:
> - enable/disable access control, anonymous access

> - choose the supported authentication mechanisms
> - set the SASL settings (host, principal, realms, etc)
Those are complicated settings, they depend on each other and other
settings. For example CRAM-MD5 or DIGEST-MD5 don't work when the
stored password is hashed (I don't know if that's a general limitation
or only applied to ApacheDS).

> - set the limits (time limit, size limit, etc)
> - keystore, certificate (and when it's migrated to the configuration, the admin's credentials)

Some additional widgets:
- enable/disable TLS
- enable/disable server-side password hashing and select hashing method


> -> Kerberos Server
> -------------------------
>
> This tab will be used to control the Kerbros Server settings.
> Users should be able to enable/disable Kerbros, as well as specifying its port.
> The following AT values will also need to be edited via the UI:
> - ads-krballowableclockskew
> - ads-krbbodychecksumverified
> - ads-krbemptyaddressesallowed
> - ads-krbencryptiontypes
> - ads-krbforwardableallowed
> - ads-krbkdcprincipal
> - ads-krbmaximumrenewablelifetime
> - ads-krbmaximumticketlifetime
> - ads-krbpaenctimestamprequired
> - ads-krbpostdatedallowed
> - ads-krbprimaryrealm
> - ads-krbproxiableallowed
> - ads-krbrenewableallowed
> - ads-searchbasedn
>
> I don't have a particular idea in mind yet on how these settings can be organized in the UI.
> If you do, please let me know.

Me neither.

Maybe we should have two sections:
- one containing the most important attributes
  - enable/disable
  - ports
  - ads-krbkdcprincipal
  - ads-krbprimaryrealm
  - ads-searchbasedn
  - ads-krbencryptiontypes
- another containing the advanced attributes


> -> Partitions Tab
> ----------------------
>
> This tab will reuse the existing Partitions Tab of previous editor versions.
> It allows the creation, edition and deletion of partitions with their specific properties (ID, Cache Size, Suffix, Optimizer Enablement, Syncho On Write Enablement and creation, edition and deletion of Indexed Attributes).
> An overview of the existing Partitions Tab can be seen at this URL:
> http://directory.apache.org/studio/static/users_guide/apacheds_configuration/configuration_editor_1.5.5_partitions.html

Ok.

For the index attributes it would be nice to show the attribute name
instead of the OID. Maybe that widget should be splitted: system
indexes (including objectClass and entryUUID) and user indexes

And a new widget to define the context entry would be nice. And a
button to generate the context entry based on the suffix (dc, o, ou)

> -> Password Policy Tab
> --------------------------------
>
> This will be used to define all settings related to the password policy sub-system.
> The user will be able to enable/disable it, and edit the following AT values via the UI:
> - ads-pwdattribute
> - ads-enabled: true
> - ads-pwdallowuserchange
> - ads-pwdcheckquality
> - ads-pwdexpirewarning
> - ads-pwdfailurecountinterval
> - ads-pwdgraceauthnlimit
> - ads-pwdinhistory
> - ads-pwdlockout
> - ads-pwdlockoutduration
> - ads-pwdmaxage
> - ads-pwdmaxfailure
> - ads-pwdminage
> - ads-pwdminlength
> - ads-pwdmustchange
> - ads-pwdsafemodify
>
> Again, I need to see how these things could be regrouped and organized.
> If you already have ideas.
>
>
> -> Replication Tab
> -------------------------
>
> This tab will be used to define all settings related to the replication sub-system.
> I'm waiting on you guys to tell me what and how replication should be configured.
> I'm not even sure we have a working configuration for this already.
>
>
> -> Options Tab
> --------------------
>
> This tab will be dedicated to more general and technical settings like:
> - denormalization of operational attributes
> - max PDU size
> - synchronization period
> - journal (location, filename, rotation)
> - changelog
> We could also put the configuration of the embedded HTTP server and webapps in there.

Pretty much.


Some more ideas:
- Indicate when a restart of the server is required (always?)
- Backup/Restore the configuration to/from an LDIF.


Thanks again.

Kind Regards,
Stefan