StrataFrame Forum

Adding items to PermissionAction enum?

http://forum.strataframe.net/Topic27026.aspx

By Bob W - 4/29/2010

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?

By Bill Cunnien - 4/29/2010

The SF business object has these options in the "StrataFrame: Security" section of the properties page. Would that work for what you need to do?
By Bob W - 4/29/2010

That is a little more advanced than what I know right now. So far I have only looked at the Role-Based Security Editor.

Could you be a little specific on where I should look for the "StrataFrame: Security" section in the properties?

Possibly point me to one of the sample projects that I can see these properties?

By Bill Cunnien - 4/29/2010

Gotcha. To access these properties, create an SF Business Object in your IDE (or simply open a business object in a sample project). It opens the object in design mode. Review the properties like you would any other object. I have mine grouped by category, so the section I am referring to is at the bottom of the list of properties for the BO. The list consists of four options:



AddSecurityKey

DeleteSecurityKey

EditSecurityKey

QuerySecurityKey



These properties represent the standard CRUD arrangement. After creating the permission key in the security editor, simply add the permission key to the appropriate property (lookup/search for the key is available). Where ever the BO is used in the application, these permissions will be checked for the specific operation.



Hope that helps!

Bill
By Greg McGuffey - 4/29/2010

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
By Bob W - 4/29/2010

Thank you everyone for your input.

It appears that StartaFrame does everything we need except, and its huge, no WPF support.

We were happy it used Visual Studio 2010 but without WPF support, it is not a product that we will be able to use.