Roadmap

From 389 Directory Server

This page contains the roadmap for the Fedora Directory Server project.

Contents

[edit]

History

History contains the history of the project, and what features were added when.

[edit]

Next Steps

[edit]

Version 1.2

The following features are planned for Fedora Directory Server 1.2. Each of the features listed here should be linked to a design document for that feature.

[edit]

Version 1.3

The following features are planned for Fedora Directory Server 1.3. Not all of these features will actually end up in 1.3, but these are the features we are considering. Each of the features listed here should be linked to a design document for that feature.

  • Support OpenLDAP client libs - allow the use of OpenLDAP client libs in addition to mozldap
  • AD integration alignment - (in order for RHDS to be used as an identity store for read only Active Directory cross forest trust we need to implement a number of features:
  • Subtree Rename and Entry Move (modifyDN with newSuperior)
  • Improve schema parser
    • fix some long standing bugs, enhance (see bugs marked with Component: Schema)
    • possibly support openldap style schema files
  • Security Enhancements
    • SELinux Policy
    • Option to disable all anonymous access, not just anonymous BIND operations
      • 1.2.0 can disable anonymous BIND operation
    • Option to control resource limits specifically for the anonymous bind identity
    • Option to disable simple bind, or only over SSL
    • Option to disable non SSL or require startTLS or require strong auth (SASL)
      • this should probably be general purpose and/or integrated with access control
      • would be nice to generalize it to something like SSF e.g. this operation requires SSF > 128
      • SSF would allow mixing SASL with TLS - may still need to differentiate between SASL/GSSAPI encryption and TLS encryption though
    • Option to turn off SASL mechanisms
    • Password Policy
      • Make the DS password policy pluggable - be able to support plugins such as cracklib
    • Access Logging
      • provide script which allows you to replace one or all log files with a named pipe script to do circular buffering, filtering, notifications, etc.
    • SMD5 (salted MD5) password storage hash
    • Restrict directory manager bind by host/IP address
    • Get rid of certmap.conf - use SASL mapping (cert auth is really just SASL/EXTERNAL)
  • Auto-generated SLAPI reference
    • generate plugin programmers reference from code + comments (e.g. doxygen)
  • Support additional standard attribute syntaxes, matching rules
  • Improve RFC correctness with respect to the new LDAP RFCs (RFC4511 etc.)
  • Move changelog into main database environment
    • Improved performance, robustness and consistency
  • Use thread aware library for complex regex searches
    • Replace aging regex code with PCRE to improve performance.
  • Support ordering of the plugins
  • Support GUIDs in ACIs to reference entries
    • confirm group filter functionality in 1.2 supports this
  • Syntax validation checking
  • improve replication conflict handling
    • current handling of conflicts can confuse searches such as KDC. perhaps create separate part of the tree to store conflict entries.
  • Data Compression
    • command line db2ldif/ldif2db can read write to pipe, so you can do db2ldif -n userRoot -a - | gzip > file.ldif.gz
    • ability to import/export compressed files via the task interface
    • ability to store/retrieve compressed attribute values (think large CRLs)
    • ability to request either a compressed value or uncompressed
    • possibly use attr subtypes e.g. ldapsearch .... certRevList;x-gzip
    • need to be able to use compressed values in replication too, especially for replica init
    • bdb may have support for compression
  • Allow authentication without an entry
    • If just using the directory server for authentication, want to allow the directory server to authenticate identities
    • This is mostly applicable for non-password based auth, or cases where the directory server is not the credential store
    • For example, cert based auth; SASL auth (GSSAPI, other cases where you pass off the auth decision to sasl), PAM pass through, other types of pass through auth
    • In this case, you want to allow the auth even if there is no user entry
    • this probably wouldn't work for simple auth (no user entry to retrieve userPassword from)
    • Need to be able to use access control, resource limits, groups/roles, CoS, with these user identities
  • Roles with explicit scoping
    • Ability to define roles/CoS that apply to scopes other than the container subtree
    • e.g. have a roleSubtree or cosSubtree attribute
  • CoS define attribute values based on regex match/substitution
    • For example, be able to define homeDirectory based on uid
    • cosAttribute: uid
    • cosDestinationAttribute: homeDirectory
    • cosRegex: s,(.+),/home/\1,
  • Log compression - compress logs when rotating
  • Log robustness - don't stop working when log volume fills up
  • WinSync attribute mapping configuration
    • support attributes other than hardcoded list
    • be able to split/join attributes
    • be able to define regex match/substitution for attribute value mappings
  • Plug-in support for languages other than C
    • python, Java, perl
  • Support for subtree and one level searches rooted at "" (i.e. null suffix support)
[edit]

Future

  • Bi-directonally linked attributes similar to memberOf (about a dozen).
  • Atomic and consistent updates for links. This might imply transactions, or some other interesting solution, but everything must be atomic so that the bi-directional links are created in one step and never get out of synch.
  • Dynamic group expansion
    • Define a dynamic group, and have the member/uniqueMember attribute of this group automatically be populated by the server
    • clients can then just search for member like with a regular static posix group
  • Configuration replication
    • we already replicate schema changes, and configuration stored in the tree (aci, roles, CoS, etc.)
    • typical use case is when adding indexes to a master, you want those indexes replicated to all consumers
    • there are many other types of configuration we might want to replicate - new databases, suffixes, sasl maps, plugin config, etc.
  • logconv.pl enhancements
    • switch to hide unindexed searches in verbose mode
  • regular expressions in ACIs
    • for example, allow a user to add or modify a value just in case the new value matches the regex. Or the group or dn of the user matches the regex...
Retrieved from "http://directory.fedoraproject.org/wiki/Roadmap"
Account