What is the best practice for providing "in-page" security.

Roger Hand

Basically, yes ... I've got three tables:

  • Role with fields Role (the PK), Description (display only for ease of admin), and RoleBit (a power of two: 1, 2, 4, 8, 16 ... )
  • SecurityRealm with fields SecurityRealm (the PK), Description and SecurityItem. You could get away with just one field here, but I found that it was useful to make the security more granular by having a Description of, say, "Trouble Tickets" and separate Items of "View", "Add", "Update" and "Delete".
  • SecurityRealm_Role which determines which Roles have access to which SecurityRealms. Only two fields: SecurityRealm and Role. Natch these just hold the keys.
The user table has a field SecurityRoleBits which is the sum of all the RoleBits for the Roles the user is a member of (remember the RoleBit is a power of two, so 1 + 2 + 8 = 11, etc. It's easiest to think of this as a binary number.)

So, given this tag in a jsp page:

<utiltags:SecurityAllow securityRealm='Customer' securityItem='Edit'>
  <input type='submit' value='Edit Customer'>
</utiltags:SecurityAllow>
The code would compare the role bits of the user (as stored in the Session upon login) with the roles that are associated (via SecurityRealm_Role table) with the SecurityRealm having Description/SecurityItem "Customer"/"Edit".

If the user is in an allowed role for this, the body content - in this case a submit button - is shown. I've also added an optional parameter to the tag that lets you specify content to be shown if the user is not allowed access.

There's a bit more to it, in that the security permissions are actually cached using a singleton object, and of course there are screens to edit all the security stuff. I also added multi-company support, so that different companies can use the same app with completely different Role names and permissions.

Good luck! Hope this helps to give you some ideas!

Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.