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

  • Support links between two attributes (like memberOf but with other/configurable attributes)
  • Support dereferencing control - http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masarati-ldap-deref-xx.txt
  • Simple paged results - http://www.ietf.org/rfc/rfc2696.txt
  • Entry USN - sort of like a per entry CSN
  • Use thread aware library for complex regex searches
  • Syntax validation checking
    • NOTE that syntax validation is off by default in 1.2.1
    • There is a new syntax validate task and script that can be used to validate data in an existing server
  • Support additional standard attribute syntaxes
    • Numeric String, Bit String, Delivery Method, Enhanced Guide, Facsimile Telephone Number, Fax, Guide, Name And Optional UID, Printable String, Teletex Terminal Identifier, Telex Number
    • NOTE that 1.2.1 does not change the schema to use any of these syntaxes yet. That will come when we update to the current versions of the standard schema from the LDAP RFCs.
  • Strict DN Syntax enforcement
    • The DN syntax has become more restrictive over time, and the current rules are quite strict. Strict adherence to the rules defined in RFC 4514, section 3, would likely cause some pain to client applications. Things such as spaces between the RDN components are not allowed, yet many people use them still since they were allowed in the previous specification outlined in RFC 1779.
    • To deal with the special circumstances around validation of the DN syntax, a configuration attribute is provided named nsslapd-dn-validate-strict. This configuration attribute will ensure that the value strictly adheres to the rules defined in RFC 4514, section 3 if it is set to on. If it is set to off, the server will normalize the value before checking it for syntax violations. Our current normalization function was designed to handle DN values adhering to RFC 1779 or RFC 2253
  • Security Enhancements
    • Add require secure binds switch
      • This adds a new configuration attribute named nsslapd-require-secure-binds. When enabled, a simple bind will only be allowed over a secure transport (SSL/TLS or a SASL privacy layer). An attempt to do a simple bind over an insecure transport will return a LDAP result of LDAP_CONFIDENTIALITY_REQUIRED. This new setting will not affect anonymous or unauthenticated binds.
      • The default setting is to have this option disabled.
  • Support OpenLDAP client libs - allow the use of OpenLDAP client libs in addition to mozldap
    • There is a new configure option --with-openldap that can be used to build the server with OpenLDAP instead of mozldap
    • In 1.2.1, the default is still to use mozldap, but those hardy souls adventurous enough can try to build 389 with OpenLDAP
    • More work is planned
  • Can now use SASL + TLS/SSL
    • earlier versions had a limitation in that you could not use SASL encrypted I/O over a connection encrypted with TLS/SSL
    • the SASL I/O layer has been reworked as a push-able NSPR I/O layer
[edit]

Version 1.3

The following features are planned for 389 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:
    • Present AD DIT style read-only view of the data stored in the DS part of the tree
      • AD clients see a DIT that looks like an AD DIT, *nix and regular LDAPv3 clients see the usual tree
    • ranged attribute values - e.g. for large static groups - MS supports attrname;M-N where M and N are numbers expressing the range
    • Need ability to specify and ordering for attribute values or the ability to retrieve attributes values in a certain order - control? attr subtype?
      • This may be needed less if the painful tool (Microsoft Managment console) is not used.
  • Subtree Rename and Entry Move (modifyDN with newSuperior)
  • Schema
    • improve parser, fix long standing bugs
    • possibly support openldap style schema files
  • Security Enhancements
  • 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
  • Plug-in Ordering
    • Allow the order that plug-ins are invoked in to be defined.
  • Support GUIDs in ACIs to reference entries
    • confirm group filter functionality in 1.2 supports this
  • 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