Hi Kiran,

On 4 nov. 2010, at 19:32, Kiran Ayyagari wrote:

-> 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
but these options need to be on GUI which actually perform the above
mentioned steps
behind the scene



-> Partitions Tab

This tab will reuse the existing Partitions Tab of previous editor
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
An overview of the existing Partitions Tab can be seen at this URL:


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.


-> Password Policy Tab

This will be used to define all settings related to the password policy
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
I'm waiting on you guys to tell me what and how replication should be
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.
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.