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.
|
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.
|
|