Doing the Safety Dance! EJBs and Security
By johnc on Jun 03, 2005
We can dance if we want to! We can leave your friends behind...
Ah yes, the early years of MTV. When I moved back from Italy to America in the early eighties I didn't speak any English. My mom and I lived in a commune up in the Oregon hills that first summer where she patiently taught me the basics. But it was MTV, G.I. Joe, and trading "your mamma" jokes by the teatherball pole in Rooftop Elementary School that really polished up my English. The image of that guy planting the MTV flag on the moon is still one of my earliest images of America.
What got me thinking about Men Without Hats this fine morning is the article that Petr Blaha and I put together on configuring security for EJBs:
NB4.1 was our first J2EE release and we obviously didn't have time to implement everything that we wanted to. Security was one of the things that didn't make it in to the graphical deployment descriptor editors, so you have to edit the XML by hand. It's not very difficult, but it is tedious and involves making lots of small changes in lots of files.
Basically you have an enterprise bean (in our case, AccountStatus) that you only want clients with security permission to access. You have to do four things:
Create a security group on the application server. In the Admin Console, go to Configuration > Security > Realms > file and add define some users in the bank_users group.
Define a security role in the enterprise application and configure the EJB module to only allow users in that security role to access the enterprise bean. In ejb-jar.xml, enter the following:
... <assembly-descriptor> <security-role> <role-name>USERS</role-name> </security-role> <method-permission> <role-name>USERS</role-name> <method> <ejb-name>AccountStatusBean</ejb-name> <method-name>\*</method-name> </method> </method-permission> <container-transaction> ...
In the web application client (the AccountState servlet), declare the security role, set up a security-constraint that limits access to the resources defined in a web-resource-collection, and configure how the user will log in. Enter the following in web.xml:
... </welcome-file-list> <security-role> <description>Bank's users</description> <role-name>USERS</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>Bank-security</web-resource-name> <description>Account information</description> <url-pattern>/AccountState</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>USERS</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <ejb-local-ref> ...
In the enterprise application, declare the security role and map it to the security group on the application server. In application.xml, enter this:
... </module> <security-role> <role-name>USERS</role-name> </security-role> </application> ...
and in sun-application.xml, enter this:
... </web> <security-role-mapping> <role-name>USERS</role-name> <group-name>bank_users</group-name> </security-role-mapping> </sun-application> ...
And Bob's your uncle! as my friend Markie Mark always says. Now for your input. We're in the process of planning what our support of security will look like in the upcoming releases and we want to hear your input, use cases, pet peeves, pointers to products that do a good job of this. Anything at all. Send your suggestions to email@example.com or post them here. Thanks!