OK, I understand both your and Scott's ideas. But my question was more of
design of permission checking and storage/configuration.
Has anybody figured out what's the best way to implement those
permissions/permission-checking classes so, that that permissions are
modifiable at runtime on per-role basis? What's the best way to encapsulate
these permissions.
The requirement is that both beans doing security checks and clients will
have to access these settings (differently). Beans need to, clients would
like to in order to modify UI depending on user's permissions.
We here got some ideas on this, but none seems to be really good:
* Use a bean that caches all permissions and synchronizes them with
database/file when changes have been made (so, this happens rarely) -- the
problem is that every bean that implements some custom security logic must
call this bean, which would become a bottleneck + inter-bean calls are slow.
So, given EJBs slow execution compared to simple SELECTS and business logic
in servlets, this would slow down application even further.
* Use a class that caches all permissions and synchronizes them with
storage. Use a bean as a facade for clients to read permissions. Beans
requiring access to permissions for checking security privileges of caller
access this class directly -- the problem with this is:
* This class has to be singleton. Otherwise big effort is required to
synchronize multiple copies with permission storage correctly
* This class has to be in the same VM as ALL the beans that need to use
it => beans are deployed in the same VB.
Additionally, we arrived to conclusion that for good security it is required
that security is, in general, implemented in lowest business layers - entity
beans themselves. So every entity beans' getDetails, setDetails and finder
methods have to be secured in general. Only in this way is security
correctly encapsulated in smallest part of objects in the system. Moving
security checks to session beans that access entity beans increases the
number of places checks have to be made... Any ideas on this?
I'm just puzzled how to design this whole thing correctly. I have not yet
found any good source of information on this. I have some ideas, but they
all have their limitations. The major concern in Speed vs.
Externalizability/Configurability. The easiest solution is still not to
externalize permissions to a storage but to hardcode them into beans (e.g.
using delegation for clearer business code).
Any comments?
Alexander Klyubin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Oleg Nitz
Sent: Wednesday, January 17, 2001 20:19
To: jBoss
Subject: Re: [jBoss-User] Externalizing security settings
Hi Alexander,
I cannot point out links that you seek for, but I have one thought on
this topic.
You may have your own Principal implementation (of course, for that
you should implement your own server LoginModule).
The Principal implementation can contain additional data and methods
used for authorization. I mean that your code could look like
public void saveAccount()
{
MyPrincipal principal;
...
principal = (MyPrincipal) _context.getCallerPrincipal()
..
principal.isAccountWriteable(thisAccount's ID);
...
}
I am not saying that this approach is good or recommended by
EJB authorities, and I doubt if it is portable,
but it is the best one that I can think out.
Regards,
Oleg
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
