Hi,

Jim, could you supply a plausible example of a transaction requiring more
than one identity/role/subject/whatever?

As I have mentioned previously the Java world may be moving in the
direction of passing the subject through the application framework to the
resource manager, as the jca resource adapter spec includes (optional)
support for connection reauthentication. This (at least potentially)
allows the app server to pass the subject to the connection for each
request without having to maintain a pool of connections for each subject.

I still haven't had time to investigate the exact nature of Firebird's
2pc/transaction support, but it would appear to me that if two connections
can participate in the same transaction (a possiblity with XA transactions)
each connection could be for a separate user, thus you could get more than
one user in a transaction, whether or not an individual connection can be
reauthenticated.

So I am at the moment thinking it would be a good idea to pass some subject
info with each db request. Whether it needs to be complete authentication
info is another question.

just my $0.02

david jencks

On 2001.05.05 13:49:32 -0400 Jim Starkey wrote:
> At 01:33 PM 5/5/01 -0400, Brad Clements wrote:
> >We use Firebird/Interbase with Zope on several systems. Unfortunately
> Zope
> logs in
> >with one connection and so its hard to equate a web-login to an SQL
> request.
> >
> >What would be interesting is being able to specify a userid PER
> TRANSACTION,
> >
> >so when I call begin(), I can pass in the userid to use..
> >
> >Maybe this is the place to do it, not in a table trigger. This would
> require changes in the
> >client and protocol, but I think would be more generally useful because
> it
> would apply to
> >any transaction, not just to a table.
> >
>
> Virtually every web application has a server process running under one
> database login acting on behalf of a client. Traditional database
> security recognizes only the database login account, leaving client
> specific security checking strictly the reasonsibility of the application
> program. In the past, this made sense. Now, it doesn't.
>
> It is clear to me that current usage for database systems suggests
> the that database system enforce two level security, which means
> the application must have some means to indicate when it is operating
> as the application and when it is operation on behalf of a specified
> client. Whether or not clients are actually known by the dbms is
> a separate and interesting question.
>
> The reason to do this is twofold. First, security policy is better
> centralizedin the database than implemented in application code.
> Second, any selection performed to implement security policy
> (row level security) is be done before request optimization.
>
> I don't think associating a client with a transaction is the right
> answer since it is possible, even likely, that the security scope
> change change within a transaction or span several transactions.
>
> What I do think makes sense is a) a more flexible role model
> that supports dynamic activation/deactivation of roles, and
> b) a mechanism for settable connection attributes accessible
> by triggers and stored procedures.
>
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>