External User Authentication

RT Developers
1

Hi all,

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:

IsExternal int2
ExternalSource varchar(16)

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
be appropriate.

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.

2

Stanislav Sinyagin ssinyagin@yahoo.com writes:

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:

A reasonable goal, but I think your implementation may have data
integrity problems. RT needs to know who it’s users are, and who they
were. a user is never deleted, because they appear in old tickets. In
a system where RT’s users are remote objects, RT is dependent on the
remote database to keep it’s users, most corporate employee databases
don’t keep former employees in them usefully.

One solution is to let RT manage it’s own users, as it does now, and
set up some sort of bulk user export. The user export would create RT
users for all other users, and set their information accordingly. You
could even do this fairly elegantly, by having users created on as
needed basis.

As for authentication, if you combine that, with apache’s
authentication options, I think you have everything you need.

seph

3

A reasonable goal, but I think your implementation may have data
integrity problems. RT needs to know who it’s users are, and who they
were. a user is never deleted, because they appear in old tickets. In
a system where RT’s users are remote objects, RT is dependent on the
remote database to keep it’s users, most corporate employee databases
don’t keep former employees in them usefully.

There could be a failover mechanism: the data retrieved from external
source are stored locally, but never used unless the external source
is available.

4

A reasonable goal, but I think your implementation may have data
integrity problems. RT needs to know who it’s users are, and who they
were. a user is never deleted, because they appear in old tickets. In
a system where RT’s users are remote objects, RT is dependent on the
remote database to keep it’s users, most corporate employee databases
don’t keep former employees in them usefully.

There could be a failover mechanism: the data retrieved from external
source are stored locally, but never used unless the external source
is available.

I meant, “while the external source is available”

5

A reasonable goal, but I think your implementation may have data
integrity problems. RT needs to know who it’s users are, and who they
were. a user is never deleted, because they appear in old tickets. In
a system where RT’s users are remote objects, RT is dependent on the
remote database to keep it’s users, most corporate employee databases
don’t keep former employees in them usefully.

There could be a failover mechanism: the data retrieved from external
source are stored locally, but never used unless the external source
is available.

what happens if the external system reuses a userid? they usually do
after a couple years.

seph

6

what happens if the external system reuses a userid? they usually do
after a couple years.

that’s mentioned in my initial proposal: the user may be administratively
switched from External to Internal, and all fields are copied then.

And since the local Users database is the primary source of information,
it will not allow duplicate user IDs within RT scope.