this has been probably already discussed. However, most
medium-to-large companies already have some kind of user database:
MS ActiveDirectory, Novell Groupware or whatever.
In order to keep the user management and password management
in one place, it would be nice to have the RT users authenticated
against those centralized databases. Also any other fields which
that database keeps, would be nice to re-use as well.
here’s a short concept of how that might be implemented in some
future. Critics, comments, skepticism are warmly welcome:
rt.Users table gains 2 new columns:
ExternalAuthId is reused from the old database schema.
When IsExternal is nonzero, some fields of Users table
are looked up externally.
ExternalSource is the identifier of one of the external sources
configured in the system.
ExternalAuthId is used as a key for external information lookup.
External source definition specifies the following parameters:
– The rt.Users table fields that are to be looked up externally.
These fields are never stored locally, and
the web interface shows these fields as unchangeable.
All other fields are stored in local database.
– Lookup method. Methods are implemented as plugins, e.g. LDAP access,
or external SQL database.
– Lookup attributes, e.g. host, bind DN, password, base DN, etc.
– Mapping between externally retrieved attributes and rt.Users table
fields. This includes the fields that are set up statically.
For instance, for all users *@mydomain.com set the
Organization and address fields to my company address.
– Procedure for creating the new user from e-mail address or
some other parameters.
– Procedure for password authentication
Password verification code must be changed. Instead of calling
crypt() explicitly, the external source’s procedure
is executed. Perhaps an additional authentication layer would
When the new user needs to be created from an incoming e-mail, or from
explicit administrative request, the external sources are looked up in
a predefined sequence, until the lookup is successful.