directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [Studio] Toughts on ApacheDS Configuration Editor version 2.0 - Comments welcomed
Date Thu, 04 Nov 2010 17:12:35 GMT
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


Mime
View raw message