> We are getting beyond my limited exposure to LDAP and LDAP
> like systems. If we need to get more technical than this
> reply, I will need to do some serious reading and
> experimenting first.

And well beyond my almost non-existent exposure. I do thank
you for your extensive reply, although I cant say that I really
agree with all of it - perhaps because I dont really understand
enough of the background.

That being the case perhaps I should keep quiet - but I wont,
that never has never been my strong point. :-)

My interest is more to do with the conceptual model. How the
public interfaces interact with the server(s) and how the
database and application designers define the security for
their systems.

As such I am interested in security from the perspective of how
I will use it as a database and application designer, and how
I will ensure that my users can tune the security in their
installations. I see LDAP, and middle tier for that matter,
as mostly implementation detail. Surely the choice of an LDAP
system versus any other auth. system will not effect how I
would define the security of my db/app design?

It seems to me that the large number of users issue is largely
a matter of concern over the fact that establishing a user
session (connection) is currently expensive, which is why it
is often resolved to use middle tiers so that connections can
be established once and shared between many users.

If network connections become one thing, while user sessions
become another thing that run over network connections, then
perhaps user sessions can be made cheap to create and destroy.
I certainly cannot see how they could be any more expensive
than effectively doing it on every transaction or request,
which would need to do much the same thing as a conceptual
user session.

If your application is one in which there is no apparent end
to a user session (or where there may be many many thousands
of users) then you write to establish and drop the session
with each transaction. No problem, you get (at least) the
performance you were expecting with the authorisation on each
request.

For applications where it is convenient to hold a session for
longer periods you get the advantages of a having a session
object to track and reference.

(Sure there are issues with respect to threading and
concurrent sessions etc etc - but these are implementation
details that I am happy to ignore for now.)

--
Geoff Worboys
Telesis Computing