dcsimg

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!