LDAP, multiple directories, enterprise

Rails
1

Hi

Sorry for a long post and maybe my poor English.

I’m writing a proposal where school staff and students from about 10-15
municipalities should be able to login to a Rails site, around 50k of
users that is.

Most of the users will only log in about 5-10 times a year so the load
on the server won’t be too high.

Roles a person can have are staff or student and this should
automatically be set from the directory. Don’t know exactly how thou.
The municipalities are using both AD and Novell and a mix of different
mail systems. Every user have both a directory-account and a
mail-account so which of these directories that will be used is not
decided yet, maybe a mix dependant on which directory hold the best
“role-information” in every municipality.

The user should be able to login to the site with his/her email address
and preferably with the existing password in original directory (this
may be a problem depend on which solution we choose)

The information we need from the logged in user is (assuming that the
directories have that information)

  • Is it a student or staff?
  • E-mail address
  • School-id
  • Class (if it’s a student that is)
  • First and last name

Before the user should log in, we will ask for the municipality and if
he/she is a student or staff.

Possible solution 1
Let rails do a LDAP-connection (SSL) on every logon-attempt

Thoughts:

Do we have to connect to the LDAP-directory on every page-load (action)
or only when the user logs in? Can we cache the lookup so when the
connection is broken the cached lookup is used instead?

Some municipalities have to let our server communicate with servers on
their internal networks or they have to setup an LDAP-directory on their
DMZ.

Possible solution 2
Build a master LDAP-server that every municipality fills with info from
their own directory, for example uploads an LDIF-file through FTP (SSL).
That file is then imported.

Thoughts:
Some directories (AD for example) won’t export the password, so every
user have to enter their email address and a “new” password, followed by
a mail to the user for email confirmation.

Possible solution 3
As solution 2 but store the accounts in a user-table in the database

Thoughts:

I believe that in maybe 5 years all this municipalities have a shared
metadirectory, that means that solution 2 is easier to change to use an
ldap-directory based on the metadirectory instead.

Possible solution 4

???

I really would appreciate some thought on this…

P.S. I have ordered “Enterprise Integration with Ruby”, I will read part
“LDAP: Harness the power of directory services”

2

Anyone?

3

Hi Magnus

Am not completely clear what your question is, but…

Making ldap (and database) queries from a website is stateless. Each
call will require authentication - as in the rails generated
database.yml file.

You could have a model that authenticates the users against ldap and
caches relevant information - role, name, etc, etc. So it’s available
for the lifetime of their session.

At a large bank, I worked on an active directory reporting system.
There was some real time lookups, but most of the reporting work was
staged a sql database. We had continuous jobs loading the database
from the active directory.

The data wasn’t up to the minute fresh, but it was good enough for
our needs. The advantage was that using a sql database was a lot
easier to create the complex reports that were needed.

For you, it will depend on what data you need - only ldap objects?
other data created by the users?

If the website is driven by a database (as opposed to ldap), you’ll
also have a much smoother development with ActiveRecord, etc

hth

4

Thanks Toby, I guess this whole post doesn’t have so much with rails to
do, more a authenticate-question.

The only reason why we will use ldap is to authenticate the user on our
site. And why we have to use ldap for this is that most of the
municipalities got their own isolated networks and their own AD (or
other brand). By isolated I mean that the only way we can connect to
them is over the Internet. So we will use a regular database for
everything else.

If the student or staff has an account in any of the municipalities own
directories, the can log in.

You answered my question on caching. I will talk to a
metadirectory-expert I know what he believes is the best solution.

I guess that it comes down to these two ways.

  1. We connect to a ldap-server at every municipality.

Downsides: maybe some municipalities refuses to let our web server talk
to their ldap-server. Maybe some municipalities doesn’t have an
ldap-server

Upsides: No delay and the user can use the same password.

  1. Every municipality have to upload a ldif (or other file) to us that
    we import

Downsides: every user have to come up with a password the first time
they log in.

Upsides: We will not be dependence on that the connection between the
site and the municipality is ok.

5

Downsides: every user have to come up with a password the first time
they log in.

For this reason, a lot of businesses (with money to spend) are using
single sign on systems. i.e. the user can log in one time and get
authenticated against a bunch of systems in one go.

Something like this would definitely do what you need, but also sounds
like overkill - in cost and time.
I’d keep it as simple as you can. Probably meaning that you wold have
your own authentication environment and not worry about connecting to
others.

Good luck!

6

Isn t the use of SSO (in our case) a way so the user don t have to login
again (if they are logged in at their own municipality), but in the
background our server still need access to a user-catalog of some kind.

Exactly that, your server would have to be a part of the same
authentication realm
as the municipality.

7

For this reason, a lot of businesses (with money to spend) are using
single sign on systems. i.e. the user can log in one time and get
authenticated against a bunch of systems in one go.

But if our server has support for SSO, won’t we still have to use LDAP
or a local user-catalog.

Isn’t the use of SSO (in our case) a way so the user don’t have to login
again (if they are logged in at their own municipality), but in the
background our server still need access to a user-catalog of some kind.