Greetings!

I am going to be posting some of my wishlist for Strata. Some of my ideas are pretty long winded, so I thought I should create a post for each one.

Better security support
I would like to see role based security implemented in the layers:

Framework
1. A global object which identifies the curernt user. This identity would include username, roles collection and whether or not the user has been authenticated. It would also include methods which allow the username, password and roles collection to be modified. Another handy utility would be a function which is passed a role as an argument and it returns true if the user is in that role.
2. A User/Role editor which can be used by the programmer in their applications. These are pretty standard and would fit nicely with some of the existing SF forms already in use. Of course, the programmer can use their own form to manage uers and roles.

UI
A RequiredRole collection for Strata UI components which is bound to a specified property which can be bound to a certain property, for example the read-only state, visibility, enabled, etc. Before a control is rendered, it checks to see if the user is in the declared role(s). If not the control's property is toggled accordingly. Forms can also respond to the RequiredRoles collection by either throwing an exception or displaying the login form, etc.

Imagine this scerio:

txtSellingPrice
  RequiredRoles = {"Manager", "Owner"}
  BoundProperty = ReadOnly

If the user logged in is only a member of SalesClerk, the selling price would be readonly. If Manager and Owner, then the textbox would be editable. In the change event, I could then allow the changes to be limited by role. For example, if Manager is logged in, allow price to be changed up to 3%, the Owner can change it to whatever he/she likes.

This would allow for a more declaritive security model. If the existing secuirty model is extended to utilize roles, the programmer can also have "low level" security hooks to do whatever they wanted.

Thoughts?

Kevin,

You'll be glad to know that this one is already in the works !  We have already started the process and plan on even allowing it to be data-driven as well.  I will elaborate on it more later, but this feature will be added to the framework. 

Sounds great! Let me know if you need testing. Can you indicate any timelines?

If you only knew, Kevin...



Like Trent said, we're developing the security right now based on the Users/Roles approach... each permission will be assigned a key, much like the localization key, and when you assign a permission key to a control/form/object, that permission is required for the user to view/interact with that control/form/object... as for a timeline, we're not sure, but it will definitely be in version 1.5. There will be a global User object that indicates the currently logged-in user (it will be a business object containing the record for that user).

Ben,

In designing your new security are you considering provding the ability to use Windows authentication and Active Directory groups (roles)?

-Larry

Larry,

The overall design is relativly encapsulated.  However, if you have a desire to use Windows Security and AD, you could easily write a program to import settings and assign permissions.

In the security scheme that you are designing it would be nice if you included an option to use Windows authentication (the Windows/Active Directory user ID and password) or custom authentication where the user ID and password is stored in the application DB. The actual roles would be defined in the framework and not Active Directory.

 

Also do you plan to support multiple roles assigned to both users and objects?

 

-Larry

Yes, we support the ability to assign multiple roles to users.  However, you don't assign roles to objects, but rather a "permission key."  When you assign a permission to a role or to a user, you assign an action along with that permission.  So, when the user logs into the system, the system builds a list of the permissions that have been assigned to that user and the action(s) for each permission.  The permissions are then linked to the permission keys that are assigned to objects within the application.

As for windows security, we will definitely keep all permissions within the application's db and out of Active Directory.  We're also probably going to allow the ability to link a particular user to the SID of an AD user to allow for Windows authentication.

You'll be happy to know that the security will be in the next release.  Probably when 1.4.1 switches from pre-release to full release.

oooh...=)

Will we have the standard strata type forms, etc. to implement the management or will we have to build something? Yeah, I know, it's lazy, but it's Sunday...=)

Looking forward to this.