On Thu, 2005-08-11 at 17:58 +0000, Firebird-Architect@yahoogroups.com
wrote:

> 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?

By designing to use LDAP (or LDAP like services), you divorce your
application completely from the security model. Your app has to know to
call aside to the security service to authorize an action, but the
security model may change (completely) at any time without altering your
application or application configuration.

Think of LDAP as a certificate based security metamodel, backed by an
RDBMS, with a standards based protocol for communication. The security
administrator (not a programmer) constructs a conceptual model that
governs the enterprise security requirements within the metamodel, to an
arbitrary level of detail.

The actual security model becomes a configuration question, not a
programming question. The application security code becomes a pattern
of something like this:


login (user, password)
{
certificate = ldap.getCertificate (user, password);
if (certificate== null)
{
loginFailed();
}
else
{
loginSucceeded ();
}
}

logout ()
{
ldap.retireCertificate (certificate);
}


proposedAction ()
{
if (ldap.checkAuthority (currentUserCertificate, proposedAction))
{
do stuff;
}
}


In your example of a J2EE like pool, the certificate is tied to the
session. However, a certificate is not the same thing as a session. A
certificate is, ultimately, a unique key that can be used to look up
what actions a session is allowed to perform.

LDAP compliant applications and datastores (including RDBMS') can be
transported between dissimilar enterprises without modification because
the security model resides in the LDAP configuration, not in code. For
this reason, while it would be desirable to embed the model in Firebird
for performance reasons, and even to expose it through an LDAP 3
compliant sockets API, it is also desirable to implement an LDAP client
PAM for sites that already have LDAP in place.

>From the apps programmer perspective, is not a matter of tuning. The

security model literally becomes someone else's problem. You just have
to know that there will be a model and that your code just needs to ask
the model for permission to proceed at key points.

If we follow this through to its logical conclusion, then embedding the
service in the DBMS and exposing it through through a standards based
API means that your application can use the exact same security model
(security data) as the underlying database.

Jim has not talked about exposing the security API yet, but once you get
to the point that you realize that his proposal is LDAP like to the
point you can speak of it in LDAP terms, exposing the model via the
standard LDAP sockets protocol for applications and for database
clusters is a no-brainer. Secure database and secure apps with the same
piece of code, and security architecture is not the application
programmer's problem any more.