Adding items to PermissionAction enum?


Author
Message
Bob W
Bob W
StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)StrataFrame Beginner (3 reputation)
Group: Forum Members
Posts: 3, Visits: 9
Our company needs more than the Deny, ReadOnly, and Grant permissions.

We also need Create, Read, Update, and Delete permissions.

Is this possible to add these permissions to the PermissionAction enum?
Also, is there a way to allow more than one permission? i.e. Create and Update?

Reply
Greg McGuffey
Greg McGuffey
Strategic Support Team Member (4.8K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
Bob,



The Grant, Deny and Readonly aren't actually permissions, they are actions allowed for a permission. You create the permissions needed for you're app in the security maintenance form. An example might help to clarify this.



Lets say you have a table that stores employee information with fields such as name, address, phone and some more confidential information like SSN and salary. You need to control access to this information. Most users won't have access to this info at all. Of those who can see it, most only can see the non-confidential information. A few in HR have full access. Of the users who can access employee information, there are variations in how the can access (CRUD).



Lets see how we might handle this using RBS (for now I'm going to just assume that the app will be able to use this info to control access...more on that later). First pass is to simply create a key to provide access to employee data:



Employee: permission to access to employee information



With this, we can now assign a user the Employee permission, with the appropriate action:

Grant - full access to emloyee data.

ReadOnly - they can view employee data

Deny - they can't access the data at all.



This is a step in the right direction, but it doesn't handle the confidential information. To handle that, add another permission:



Employee: permission to access non-confidential information of an employee

EmployeeConfidential: permission to access confidential information of an employee



Now we'd have more options. Here is a partial list to get you thinking:



Employee EmployeeConfidential Access

-------- -------------------- --------------------------------------------

Deny Deny No access to employee data

Grant Deny Access to non-confidential data only

Grant Readonly Full access to non-confidential, read to confidential

Grant Grant Full access to all data



Getting closer. What about differential access based on CRUD? Just add permissions specific to the type of access required. I.e. rather than permission to the Employee data (or confidential employee data), the permission is now to update the employee data, etc.



Employee: permission to view non-confidential employee data

EmployeeConfidential: permission to view confidential information of an employee

EmployeeUpdate: permission to edit employee data

EmployeeAdd: permission to add employee data

EmployeeDelete: permission to delete an employee record.



Now, a user can be assigned the correct combination of permissions to control access in a very fine tuned manner. Essentially, the Employee and EmployeeConfidential permissions control what they can view. The EmployeeUpdate, EmployeeAdd and EmployeeDelete keys control what they can do to the data.



Note that the names of the permission are completely under your control. I've named them this way so that they sort together and I can see all Employee permissions together in the security maintenance form. Also note that you can create folders to organize permission too.



Of course, it could be a real pain to manage this for the users, which is were roles come in. A role is a set of permissions with associated actions that can be assigned to a user. Thus, I might have a "manager" role that has the Readonly action for the Employee permission, and a "HR" role that has Employee and EmployeeConfidential with Grant actions, plus the update/add/delete permission with Grant action for employees.



To implement this, you need to setup the permission/roles and assign those to users. Then you need to setup your BO to have the appropriate permissions. In this case, we need to setup field level permission (to handle confidential info) and the security keys Bill was talking about. The field level permission are setup in the BO Mapper (rebuild it after setting them up). If you didn't have the need for field level security, there is a security key at the form level which can be used (or alternatively, you could have two form, on with and one without the confidential info). Again, see the help file for details.



Hopefully this helps you see how you can manage very, very complex security requirements with the RBS module. I've been very please with it. I'll be happy to attempt to help more if needed. BigGrin
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search