On 11/4/10, Pierre-Arnaud Marcelot <[email protected]> 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 <[email protected]> >> 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
