Hi Adrian Thanks for the reply the article was very helpfull, I would appreciate some more advice on this please
I am trying to create a form to create users and make them members of certain groups with permissions set for those groups. Using the table structure you suggested to me some time ago shown below What would you suggest the best way of adding users and their groups and their permissions for those groups would be. I have created a form so far (shown below) that adds the users details to the users table I now need the best way of creating an interface to go with the form above for selecting the groups that a user belongs to and what permission is set for that group ? I thought it would it be best to use check boxes to select the groups a user should belong to, but then I have the problem of assigning a permission to each of the groups selected in the check boxes?? I would appreciate your advice on how to achieve this ? Thanks Ian ----- Original Message ----- From: "Adrian Lynch" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Wednesday, May 28, 2003 12:09 PM Subject: RE: Populating Related Tables in Coldfusion > The following might give you some ideas. A bit long but worth it. > > From Hal's latest newsletter... > > --------------------------------- > > Rethinking Roles-based Security > > Chances are good that if you're using security on your > applications, you're applying some form of roles-based security > model. The main feature of this model is that access is > restricted to certain groups or roles. Such security schemes > often have the user linked to a comma-delimited list of user > groups they belong to, with such a list being placed into a > persistent scope. A sample list might look like this: > > <cfset session.currentUser.userGroups = "admin,supervisor" /> > > The challenge mechanism then may look like this: > > <cfif ListFindNoCase(session.currentUser.userGrousp, > aRequiredPermission)> > Come right in > <cfelse> > Not on my watch, pal... > </cfif> > > ColdFusion MX supports this by providing an access attribute for > the <cffunction> tag that works in conjunction with the > <cflogin> tag to automate this scheme. I want to suggest some > other aspects of security for environments in which change is > the norm. In the process of exploring a solution for this > problem, we may learn a lesson in better software design. > > First, what's wrong with roles-based security? Initially, not > much. It's simple to implement and it's effective. It does > require you to place individuals in a user group, but this is > common practice when adding a user into the system. When done, > we have a direct mapping between the user group and access to > protected areas of code. > > But the notion of "direct mapping" poses a subtle problem--one > that often lies hidden, only to reveal itself when we least want > or expect it to. To uncover the problem, let's perform a few > thought experiments. First the situation: we have three user > groups defined in our system: RegisteredUser, Supervisor, and > Administrator. When a user is registered with the system s/he > can be place in any or all of the user groups. (This may be a > good deal simpler than the environment you're operating in, but > the principles for roles-based security remain the same.) > > Andy, Bob, Carmen, and Dawn are new hires and are placed into > the following user groups: > Andy: RegisteredUser > Bob: RegisteredUser, Administrator > Carmen: RegisteredUser, Supervisor > Dawn: RegisteredUser, Supervisor, Administrator > > Now for the thought experiments: > > 1. A business rule tells us that junior new hires like Andy > (with only a RegisteredUser role) have limited access to the > system for an initial, probationary three month period. This > does not apply to Bob, Carmen or Dawn. If we have a direct > linking between user group/role and access, we have a problem. > We will need to modify our challenge code so that it tests both > for RegisteredUser and performs a DateDiff() against the > hireDate and the current date. Must we put Andy in a special > user group during his probationary time period? That causes > problems unless we're operating on a small scale where we have > control over all aspects of code and security. > > Further, you can imagine that over time, the challenge code > could grow to be more and more complex. And let's say we've > implemented separation of logic and presentation (perhaps using > the Model-View-Controller pattern) that our fundamental business > logic code (including data persistence) serves more than one > application--each possibly with their own sense of user groups > and special logic. Is there no solution for the spaghetti code > that is bound to follow? > > 2. What happens if the situation occurs where users from other > systems--not in our user database--want to use parts of our > system? All that we receive is a user validated on their home > system with their user groups. It's unlikely that their user > groups will match with ours. Adding these users into our system > may be impractical and certainly presents a problem of > duplicated data with synchronization issues. How can we give > them access to the parts of our application we want them to > have? > > 3. What happens if an existing user group is to be granted new > permissions? Say that previously only administrators could > delete a user, but now we want supervisors to be able to delete > users. Note that we don't want to turn supervisors into > administrators--we just want to extend their permissions. > > 4. What if we wish to promote or demote a specific user? Perhaps > one of the RegisteredUsers is a team lead and is to be given > additional access--but again, without changing their user group? > > 5. Your application is so successful that your company decides > to sell it to others. But what user roles will these new > customers have--and what access rights should be assigned to > them? > > These situations are similar in that they require that we go > outside the prescribed security model in order to solve the > problem. When we find ourselves writing such ham-handed code > (called a "kludge"), we're actually getting important > information that our model does not match sufficiently well with > the real world. When we find this, the best solution is often to > re-examine the model to see where we've gone wrong. > > In the case of security, the problem is the direct mapping > between user group/user role and challenge code granting or > denying access. We can solve this problem easily if we separate > the idea of permission from a user role. Let's introduce an > analogy that may clear things up. Imagine that, instead of > dealing with code and permissions, we're dealing with an office > that has doors. Some of these doors have locks on them and a key > is required to open them. > > Locking doors are in no way tied to specific user roles: they > were created by the manufacturer. The manufacturer also provided > a key to these doors. It is up to the security officer of the > building to determine to whom to give keys. Now, for the sake of > convenience, it may be that we will give the key to the > executive washroom to all members of the Executives group. But > we also want to give access to the cleaning company. This > presents no problem for the door follows a simple rule: if you > have the right key, you can enter. > > We would do well to adopt a similar scheme. When we build our > code, we determine that areas should be locked. Instead of a > key, a specific permission is required to use the code. Our > challenge code follows a simple rule: if you have the right > permission, you can enter. > > But surely, we don't want to have to assign permissions to each > person? No. One way to automate the process is to let everyone > that is in a user group have certain permissions mapped to them > at run time. But all this means is that a tedious process of > associating individuals with permissions is automated--it does > not change the fundamental nature of that process. > > When a user reaches a locked door (to extend the analogy), they > are interrogated for a permission (not a user group). In order > to get that permission, they must first have gone through a > "permissions binding" phase which assigns runtime permissions to > them. This component needs access to a map from which it can > determine that some aspect of a user (user group, SSN, name, > etc.) maps to one or more positions. As an example, the map may > say that Administrators maps to addUser, editUser, deleteUser > and createUser while RegisteredUser maps to editUser only. > > Let's review the five thought experiments and see if this > improves things: > > 1. Andy's special case is handled in the permissions binding > phase by removing certain permissions that he would have had by > virtue of being a RegisteredUser. Depending on what the special > case is, the code involved could be quite complex. At challenge > time, though, the only thing that matters is the possession of > permission--regardless of what rules the permissions binder used > to assign those permissions. > > 2. Users who aren't part of our database may not have user > groups that match up with ours. But the permissions binding > doesn't require them to be in one of our groups--only that some > aspect of that user that is provided to us can be used to > determine permissions. In this case, we are given the user group > of the foreign user, which we can map to individual permissions. > > 3. Adding permission to an existing group involves only a change > in the permissions binding table, since all permissions binding > is done at run time. > > 4. Since the use of user groups is merely a convenience (as far > as permissions go), we can add to or take away from the user any > specific permissions we wish to. Again, this logic would go in > the permissions binding code. > > 5. Since no direct mapping is made between user groups and > challenge code, we don't need to know prior to runtime how to > bind permissions to users. > > How you build a permissions binding mechanism depends on what > framework (if any) you have in place. In Fusebox 4, each circuit > and each fuseaction has an optional attribute called > "permission". These attributes can be used by someone writing a > security plugin to ensure that the user's available permissions > matches the required permission for circuit and/or fuseaction. > > For example, here's a circuit.xml.cfm file from a sample FB4 > application: > > <circuit access="public" permission="useQuizBuilder"> > <fuseaction name="deleteQuiz" permission="deleteQuiz"> > ... > </fuseaction> > > <fuseaction name="viewQuizzes"> > ... > </fuseaction> > </circuit> > > Fusebox itself does not apply any security check, but does make > the values set in these attributes available to the programmer. > It then becomes a simple matter of a few lines of code to write > any challenge code you wish. For example, we might write a > plugin to ensure that to use any fuseaction in the circuit, the > user must have the useQuizBuilder permission. If the user wants > to delete a quiz, s/he can now be challenged for the deleteQuiz > key. > > The rules for permission binding can be stored and gotten from > database table(s), XML files, .ini files, through the use of web > services, etc. For more info on Fusebox 4, come to > beta.fusebox.org. > > At the beginning of this newsletter, I said that we may be able > to learn something about designing better software. I think we > can. The problem with the direct user group-to-challenge code so > often employed is an example of a much larger class of problems > in which two components are tightly bound together. Tightly > bound components tend to be fragile, breaking with changes in > the environment and requiring kludge code to keep the system > running. The solution for the security model was a complete > separation of one design time component (user groups) with > another (challenge code). The two are dynamically bound together > only at run time. By following a similar course for similar > types of problems, we can help ensure that our code is robust, > adaptive, and long-lived. > > ---------------------- > > -----Original Message----- > From: Ian Vaughan [mailto:[EMAIL PROTECTED] > Sent: 28 May 2003 11:58 > To: CF-Talk > Subject: Populating Related Tables in Coldfusion > > > I am trying to populate several tables in access that are related to each > other and would like some advice on what you think > the best interface would be to populate these tables with Coldfusion. > > I have created an interface (form) to populate the Users table I just need > some advice on the best approaches on how to achieve an interface on > assigning groups and permissions to the user you are creating. > > Any ideas would be most welcome > > These are my tables that need to be populated from an interface > > Groups Table > GroupID , GroupName > > UsersTable > ID, Username, Password, Name etc. > > Permissions > PermID, PermName, Enabled > > UserGroupMembership > UserID, GroupID > > Usergrouppermissions > PermID, GroupID, UserID > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
