See below.
> 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.
>
The requirement that a singleton security bean exist in each VM that needs to access
the security policy does not force you into a single VM solution. There are many ways
to efficiently distribute the security policy changes across VMs via push:
JMS topics,
JINI events
Custom multicast socket programming
> 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?
>
This I don't agree with. In my experience the data or business logic needs to
be indepdendent of the security policy as this changes as a function of the
deployment context. Think about it in terms of someone who is writing EJBs
as resellable components. There is no way you can code a security policy
that is going to satisfy every use case of the same data/logic.
> 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).
>
Just start prototyping some of your ideas and decide which tradeoffs are
acceptable. Security in distributed environments is still a relatively new topic
so there aren't any definitive references.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
