Yes; that's exactly what I'm talking about. :-)
My company does higher education software. No one fusses
about access control like higher education people. :-) It's not just
multitenancy--it's support for hierarchies, etc. So: divisions,
departments, etc.
A simple tenant identifier is just not enough, as I'm sure you know. Think of cases like:
this faculty member may see only certain fields of students that are
being advised by him or one of his colleagues that he subs for from time
to time. We would desperately like this sort of thing to be
intercepted at the
WHERE clause level, but, because this sort of thing
varies from school to school, we don't necessarily know what the
rules--and hence the JPQL parameters--are going to be. We would
desperately like JPQL like
SELECT s FROM Student s to simply
work, given
some sort of access control layer that exists on top of or alongside
it.
We
might be able to make use of
@AdditionalCriteria plus some set
of standard properties that we always set on the
EntityManager--I
haven't thought about it enough, frankly--but it seems to me that it
would be better if this sort of thing were treated as a kind of aspect
on top of (or off to the side with respect to) JPA, rather than as
something that we have to manage while we're interacting with the
EntityManager. The
jpasecurity project is far from perfect in many
respects, but it at least has the right (IMHO) root goal here: treat
security like a bunch of
GRANT statements and try to stay out of the way
of the business code. I would love it if this mindset would make it into the JPA specification.
Please feel free to contact me directly if this sort of thing is an
interesting use case.
I will make a point of going through the links you provided; thanks for that.
Best,
Laird
