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”?

image with no caption

Note

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

Note

The Container will use a <security-role-ref> mapping even IF the programmatic name matches a “real” <security-role> name.

When the Container hits an argument to “isUserInRole()”, it looks FIRST for a matching <security-role-ref>. If it finds one, that’s what it uses, even when the hard-coded name really DOES match a <security-role> name. Think about it—you might really HAVE a “Manager” security role in your company, but it might mean something completely different than what the programmer intended. So you could, for example, map hard-coded “Manager” to “Admin”, and then map a hard-coded “Director” to “Manager”. So, the <security-role-ref> always wins when both include the same <role-name>.

Sharpen your pencil

Assume all security constraints below have the same <url-pattern> and <http-method> elements. Based on the combinations shown, decide who can directly access the constrained resource.

 

Nobody

Guest

Member

Admin

Everyone

  1. <security-constraint>
   ...
  <auth-constraint>
    <role-name>Guest</role-name>
  </auth-constraint>
</security-constraint>
     

  1. <security-constraint>
  ...
  <auth-constraint/>
</security-constraint>
     

  1. <security-constraint>
  ...
  <auth-constraint>
    <role-name>Admin</role-name>
  </auth-constraint>
</security-constraint>

<security-constraint>
  ...
  <auth-constraint/>
    <role-name>Guest</role-name>
  </auth-constraint>
</security-constraint>
     

  1. <security-constraint>
  ...
  <auth-constraint>
    <role-name>Guest</role-name>
  </auth-constraint>
</security-constraint>

<security-constraint>
  ...
  <auth-constraint>
    <role-name>*</role-name>
  </auth-constraint>
</security-constraint>
     
  1. image with no caption
     

  1. <security-constraint>
  ...
  <auth-constraint>
    <role-name>Member</role-name>
  </auth-constraint>
</security-constraint>
<security-constraint>
  ...
  <auth-constraint/>
</security-constraint>
     
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset