directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed
Date Fri, 05 Nov 2010 10:48:59 GMT
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."
>> ->
>>>> - 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


> [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:
>>> 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

> [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.

View raw message