directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed
Date Thu, 04 Nov 2010 18:32:03 GMT
On 11/4/10, Pierre-Arnaud Marcelot <> 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 <>
>> 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
+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."
> ->
>>> - 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
>>> -> 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:
>> 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

View raw message