""Roman Rokytskyy"" <rrokytskyy@...> wrote in message
news:dd2pmi+7ffk@......

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

That's what I meant :) 'Client' is quite confusing in n-tiers.

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

Which authentication methods are used?
Where security accounts are stored?

> 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

So if I understand you:

An application server starts under its own identity (A) and initially
authenticates itself (A) to db server. A db server checks if A is a
trusted identity in such a sense that it is allowed to use a defined
set of roles (R1, R2 for example). This can be formulated as A is
authorized to use roles R1 and R2:

create user A identified externally;
grant role R1 to A;
grant role R2 to A;

Suppose the app server receives a user request. It authenicates a
user by some means, and determines its identity. Based on the
identity it chooses role R1 or R2 and sends it to the database. The
database trusts the role and performs further security checks based
on that. The database doesn't have to perform any authentication
since it trusts A to use roles R1 and R2.

However, this security model can be equally implemented if app server
performs security checks by itself and doesn't send database commands
that could violate the choosen role permissions. From the database
p.o.v. it's no difference if the app server _voluntary_ restricts
user's requests or _voluntary_ sends role name that would futher
restrict its permissions.

BTW, do you think this model is different from SQL standard roles,
except several roles can be active at a time?

Huh? Does this picture corresponds to your view a little bit?

In the other scenario the app server passes the security context
obtained from user authentication, instead of authenticating itself.
That would imply that:

-- app server is not authenticated. The database sees only end user's
identity.
-- each time the application starts actions on different user's
behalf, it should propagate user's security context to the database,
since that may be expensive, a permanent security session may be
helpful;

Thinking more fantastically, it may be event possible to pass _both_
security contexts so the final set of roles could be a combination of
roles obtained from both contexts. Not sure it is of some practical
interest.

> 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

So the application does not choose roles? If so, how they are
determined? Is there some system-level mapping of user identity to a
set of role names? How that mapping is stored and how it is protected
so that the database server can trust it?

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

That would be enough, I think.

> 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).

Interesting, which types security environments are used today? Surely
there are NT domains. SSL + certificates? Any others?

Regards,
Aleksey Karyakin