Head First Servlets and JSP, 2nd Edition

The declarative side of programmatic security

There’s a good chance that when a programmer hard-codes security role names in a servlet (to use as the argument to isUserInRole()), the programmer was just making up a fake name. He either didn’t know the real role names, or he’s writing a reusable component that’ll be used by more than one company, and those companies aren’t likely to have the exact role names the programmer used. (Of course, if the programmer really wants to build reusable components, hard-coding a role name is a Terrible Idea, but we’ll suspend disbelief for now.)

It turns out that the Deployment Descriptor has a mechanism for mapping hard-coded (which means made-up) role names in a servlet to the “official” <security-role> declarations in your Container. Imagine, for example, that the programmer used “Manager” as the isUserInRole() argument, but your company uses “Admin” as the <security-role>, and you don’t even have a “Manager” security role. So even if you can’t stop a programmer from hard-coding a role name, you at least have a work-around when the hard-coded roles don’t match your real role names. Because even if you do have the servlet source code, do you really want to change, recompile, and retest your code just to change every instance of “Manager” to “Admin”?

Note

The <security-role-ref> element maps programmatic (hard-coded) role names to declarative <security-role> ...