Re: secure tag and permissions

Fri, 05 Apr 2002 11:44:12 -0800

Hi McE,

Actually, I was writing all of this up yesterday, but left off half way through when I decided that nobody would be particularly interested...

Using your definitions, Patrick, I simply do not deal with Permissions or Roles.  I have People and I have Groups.  Data about People and Groups is stored in LDAP.  My global authentication function confirms who you are, and creates a "session" variable that contains a list of all the Groups that you are in.

So what are these Groups?

Although the authentication/authorisation/customisation system thinks all Groups are exactly the same, conceptually there are two different kinds of Group: IndependentGroups and ApplicationGroups.

IndependentGroups exist independent of any IT system - they are social and organisational constructs.  Where I work, I am a member of these:

  • RTA
  • Information Management and Information Technology Branch
  • Application Development and Maintenence Section
  • Web Unit
  • Web Application Team
  • Team Leaders
  • Contractors
  • ...
ApplicationGroups only have meaning in the context of particular IT systems.  They are what I would usually describe as "roles" (as opposed to your role definition, Patrick).  I am a member of many ApplicationGroups (I have many roles):
  • WWR-users
  • WWR-admin
  • STC-users
  • STC-images
  • STC-admin
  • STC-audit
  • ...
So, what do I do with these?
 
The API of my authorisation/customisation system has a single function,
isMember(GroupList).  It returns a Boolean value which is true if the authenticated user is a member of one of the Groups in the list.
 
So the simplest way to secure or customise a piece of code using this function is like this:
<cfif isMember("Web Unit, WWR-users")>
  <a href="index.cfm?fuseaction=wwr.default">Web Work Register</a>
</cfif>
 
In practice, though, it's more likely to look like this:
<cfif isMember(WWRGroups)>, where WWRGroups is a list that has been defined in fbx_settings.
 
Now it's perfectly okay, and often done, to do this:
<cfif isMember("Web Unit, WWR-users")>
  <cfset WWRflag = true>
</cfif>
...
<cfif WWRflag>
  <a href="index.cfm?fuseaction=wwr.default">Web Work Register</a>
</cfif>
 
... but that is only done when a large clump of code needs to ask that same question several times.  Testing the flag is quicker than testing isMember() repeatedly.  In other words, that's a coding decision, not an architectural or modelling decision.
 
That's all there is to the authentication/authorisation/customisation system.  The Coder may choose to create flags representing permissions if they wish, but that is not the conceptual level at which the system was designed.  The basic concepts are People, Groups, and BusinessRules ;-)
 
That's about it.  I built this system about three years ago, because Advanced Security seemed far too arcane, and we use it across some 100 Intranet applications now.  I hope I didn't get it all badly wrong ;-(
 
See ya,
LeeBB

----- Original Message -----

 
I understand Hal's point of view. It makes perfect sense.

But Lee, I'm still trying to figure you out.

First, some definitions:

User:
A person

Group:
A set of people, who have some application-independent
property (such as job title) in common. (ex: Manager)

Permission:
Something that the user can do. (ex: FlushEBtoilet)

Role:
A set of permissions. (ex: UseEB)


So Lee, are you saying that we don't need groups
because we can accomplish the same thing by
assigning users directly to roles?

Are you saying that permissions are too granular, and
we can get by just fine having the code deal directly
with roles?

That is, instead of
<cfif hasReadArticlePermission>Read this article</cfif>
<cfif hasSearchArticlePermission>Search this article</cfif>

this works okay for you:
<cfif isArticleReader>
  Read this article
  Search this article
</cfif>


Am I getting close?

Patrick

==^================================================================
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================

Reply via email to