Nando, This gets back to my point about using roles for what they were originally intended, which is an actual role played by a user. Some users may serve in more than one role, which is fine, but you have to have a clear definition of what that role entails. Confusion sets in when people start using roles for things other than roles, like a collection of permissions. When you become granular down to the point of individual permissions, you start losing the concept of a true role, and instead have to manage a handful (or more) of individual permissions.
Most of the time this can be resolved by rigorously applying solid business process engineering principles to the requirements gathering process, during which you'll discover clearly defined roles played by users rather than "things someone might need to do." The whole "let's give Bob permission to open the safe and take money out of it" approach of adding individual permissions directly to a user is dangerous to say the least, and can often be traced to insufficient requirements gathering. It's in those smaller apps that you mentioned where such problems generally occur. Typically it's not easy to refactor a loose collection of permissions into a formal set of roles, but the benefits outweigh the cost. The whole permission/anti-permission model reminds me of the hellish days of Novell NetWare 3.11's security model with its "Negative Rights Mask." Uuuhhuugguhuuhhh...! Respectfully, Adam Phillip Churvis Member of Team Macromedia Advanced Intensive Training: * C# & ASP.NET for ColdFusion Developers * ColdFusion MX Master Class * Advanced Development with CFMX and SQL Server 2000 http://www.ColdFusionTraining.com Download CommerceBlocks V2.1 and LoRCAT from http://www.ProductivityEnhancement.com The ColdFusion MX Bible is in bookstores now! ----- Original Message ----- From: "Nando" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 13, 2004 10:43 PM Subject: RE: [CFCDev] How smart should objects be? > Well, i kinda like to call a spade a spade in my code, because it helps me > immensely to sort out what's going on conceptually. I realized awhile back > that i could be doing the same with the role mechanism in CFMX, but in > reality, the code needed is so simple there's no reason not to write it. > > As a personal preference, i appreciate very much not needing to translate > the concept in my head everytime i run across a part of the UI or a function > that needs a permissionKey. I've got enough to keep track of in my mind as > it is. And using a misnamed variable has led me astray many a time. So by > now, i take great care in naming my variables and objects. > > To me, Role might be used to determine a set of keys for a user, adding > another level of abstraction if needed. But in my experience, it's ALWAYS > happened in even the smallest apps that a user with a certain Role needed a > permission that happened to be in a different Role. So even in the case when > you use Role to determine a set of permissionKeys, i'd build it into the app > to be able to assign a Key independent of Role. > > :) n. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Adam Churvis > Sent: Saturday, August 14, 2004 4:22 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] How smart should objects be? > > > Nando, > > It seems like the keys in your security model map to roles in the MX > security framework, and the locks map to tests for IsUserInRole() that > determine whether or not the user is in a role (has a permission key). > > It sounds like the only difference might be one of granularity; > "permissions" tend to describe many individual things a user may do, while > "roles" tend to describe a set of permissions that a person serving in a > role might need to have in order to accomplish that role's job. > > Am I seeing your model correctly? > > Have you worked much with the MX security framework? I'd be interested to > hear your thoughts. It seems like lots of folks don't really use it in > favor of the code they brought with them from CF5 and earlier days. > > Respectfully, > > Adam Phillip Churvis > Member of Team Macromedia > > Advanced Intensive Training: > * C# & ASP.NET for ColdFusion Developers > * ColdFusion MX Master Class > * Advanced Development with CFMX and SQL Server 2000 > http://www.ColdFusionTraining.com > > Download CommerceBlocks V2.1 and LoRCAT from > http://www.ProductivityEnhancement.com > > The ColdFusion MX Bible is in bookstores now! > ----- Original Message ----- > From: "Nando" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, August 13, 2004 10:02 PM > Subject: RE: [CFCDev] How smart should objects be? > > > > Marlon, > > > > I'm a big fan of permission based security, and found that a lot of fuzzy > > thinking cleared up when i got my head around this approach. There are 2 > > aspects to consider, the KEY and the LOCK. > > > > Any process or any part of the UI that needs to be secure has a "lock" (an > > if statement) like a door has a lock, and users run around with a set of > > keys (mine are in a structure, let's call it permissionKey for clarity's > > sake). If your users are running around your app encapsulated in user > > objects, then when they login, they get their permissionKey ring and it > gets > > stored as a struct in the variables scope of user. Then a simple call to > > session.myUser.getPermissionKeys() at the beginning of the request will > sort > > the UI stuff out right nice. Inside another object, you'll need to pass > > either the userObj or the permissionKeyRing in, your choice. > > > > At the moment in my apps, permissionKey is just an attribute of user. An > > admin assigns the keys when the user is created, and the user's > > permissionKey ring is persisted (in my case, as a wddx in a DB field.) > > Simple > > > > The other half, the lock part, seems like it *should* be some object > > somewhere, but in practice, it's probably just hardcoded into your app > here > > and there. If you need the LOCK part variablized and hence encapsulated > > (first rule of OO, encapsulate what varies, if the LOCKS don't vary much, > > hardcode them) - then you might have to put your OO thinking cap on and go > > at it. But I think in most apps it's apparent ahead of time what needs > > security and what doesn't. > > > > Does that help? Anyone else wanna discuss / debate this after hours? > > > > nando :) > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
