> Why do you think that? The point of authorization (which roles are
> for) is to restrict users of doing thing that they shouldn'd do.
> Switching roles seems to be proposed as a voluntary action from the
> db client. In other words, the client becomes responsible for
> limiting its own abilities. How do you see this model works at all
> (from the security p.o.v.)?

The main idea is that not the client limits its own abilities, but the
application server. Please excuse that this description will be J2EE
specific - I have no idea whether same is possible in .Net.

When I deploy the JCA connector in application server for some
database, it already has a possibility to perform a connection on
behalf of some subject - the subject is passed into relevant methods.
At present this feature is ignored in JayBird (user name and the role
name are specified in the configuration but can be overwritten from
subject, role name is taken from configuration).

The new scenario would be the following. When user authenticates
himself in JAAS, the security module assigns this user a role name it
has for a database connection. This happens transparently to the user.
Then, since each access to the application happens on behalf of that
authenticated user, the subject (an entity associated with user that
contains public and private credentials - part of JAAS) will be passed
to the JCA connector when a connection to the database is obtained
from the connection pool. The JCA container switches the role of the
user on the fly and all subsequent database calls happen on behalf of
that user. At the end connection is returned back to the pool and a
new role is specified for a new user.

So, not the application is responsible for role switching, but the
J2EE container that provides the connections. And this can be done on
per user basis. This is possible already when the connection is
obtained each time a new combination of user name/password and role is
passed. But it is not possible in case of connection pooling.

> I think the most needed and tangible feature is a "single sign on".
> However, it is related to authentication (not authorization) and has
> nothing to do with roles. Correct me if I wrong.

If we say that all permissions are granted to roles and the
user/password is needed in server only for authentication purposes,
while authorization is based on roles, the feature above solves the
single-sign-on issue too. True, that will work for now only in J2EE
world (possibly in .Net), but that means only that something similar
to JAAS has to be invented for other application servers (and at the
end JAAS is the well-known PAM but for Java + TLS for subject storage).

Roman