Usually, it's preferable to set up access control by declaratively defining method permissions in the enterprise bean's deployment descriptor. Such container-managed security makes an enterprise bean more flexible, since it isn't tied to the security roles defined by a particular application. Security holes due to programming errors is also less likely with container-managed security, since the security mechanism is implemented by the container.
.... <enterprise-beans> ... <entity> <ejb-name>AnEntityBean</ejb-name> <ejb-class>AnEntityBean.class</ejb-class> ... <security-role-ref> <role-name>root</role-name> <role-link>super-user</role-link> </security-role-ref> ... </entity> </enterprise-beans> .....
.... <assembly-descriptor> <security-role> <description>This is the security-role for the security role "root" referenced in the AnEntityBean class</description> <role-name>super-user</role-name> </security-role> </assembly-descriptor> ....
In an enterprise setting, such information can be stored in the directory server, or persistently in database tables.
3. In an application that has two servlets - one of which is protected under the security model for the application while the other is not - will the security model kick in if the unsecure servlet forwards a request to the secure servlet ?
No, the security model will not intervene if the secured servlet is being requested by a