Hi Laird,
Have a look at @AdditionalCriteria or our @Multitenant solution.
http://wiki.eclipse.org/EclipseLink/Development/AdditionalCriteria
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Single-Table_Multi-Tenancy.
Cheers,
Guy
On 30/06/2011 10:17 AM, Laird Nelson wrote:
Hello; thanks for a great product and congratulations
on the 2.3 release.
I have a question around security and customization, and am
looking for thoughts on how best to proceed.
In the higher education industry (and I'm sure many others),
access control is paramount. You don't want a work-study student
being able to see the salaries or account balances of professors,
for example.
My question is, what is the best way--or any way, really--to
affect a query such that a subset of what is requested is actually
delivered?
Suppose we have a JPQL query like this:
SELECT
p.salary FROM Person p
But the security rules that should be in effect are: "Users in the
'workstudy' role may only retrieve salary information of other
work-study students". (I am making this silly rule up.)
So when a query is run from our app, we really want it to
translate, as silently as possible, to:
SELECT p.salary FROM Person p WHERE some condition
that determines whether p is a work-study student based off p
and maybe other information
Loosely speaking, we'd like to inject a WHERE clause in there where none
was there before. Or, in the case where there was a WHERE clause,
we want to add a condition to it. And in the case of complicated
joins, we might want to add additional conditions in there as
well.
Leaving aside the problem of passing parameters for the moment, is
there a single place where such a condition could be injected?
I'll come back to parameters if unparamaterized constraining is
possible.
I should note that I am well aware that I could filter the List of
query results, but I'm looking to push the constraining
information down to the underlying database itself. I'm also
aware that what I'm asking about is more likely than not not
possible.
Thanks,
Laird
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
