The application I am considering StrataFrame for is project based. I.e. the data is all related to a project and the users role is based on project. On one project a user might be the project manager, having more permissions and on another she might be a reader, only able to view data, no edit/add/delete it. Is this possible using StrataFrames security?



As I see it, the user would be authenticated, then I would need to see what project they are working on and then change their role. This is probably covered in the helf file, but I'm running out of time to evaluate StrataFrame :-/



Thanks for you help!

This is definitely possible.  There are several ways to go about this.  The easiest would be to create two separate security projects.  One for project A and another for project B.  This way the two do not have to co-exist.  However, if you would prefer to move roles and permissions around, this is possible.  Some of this may be resolved for you when you look through the security and get a little more in depth and see how it ties into the application when you distribute your application. 

Another option, for example, is to do what I mentioned above with the two different security projects.  But if you are using the same application assemblies (same EXE) you could just swap the security database key based on which project they are running.  This would just entail that you have the security data in two separate databases and you just point security to which database you want to use based on the project.

I would need more information to give you a solid recommendation, but there are a number of ways to "skin the cat."

I don't see how multiple security projects would help. First, there aren't two, there are many (n). Second, the projects are time limited, with new ones all the time. Wouldn't this mean creating the permissions as well as roles in each project? This seems like it would be a huge duplication of effort.



However, you say I can reassign a user's role on the fly, and I assume maybe permission also. Could you provide some sample code, so I know that objects and methods I am to use?



Thanks!

Based on your previous post, you used the term "project" which generally entails completely different assemblies or applications...thus the different security projects.  Before I try to give you a sample, I guess it would be best if I understood what you were trying to accomplish.  Is the user whose account you want to change going to be going into the same application or different applications?  Are the two applications related at all, other than trying to reuse the security permissions and roles?

Ah! I see the confusion. Not projects at all in terms of development, rather the client I'm building the app for has projects. I'm building an app to help them consult with many clients on many projects. The app alwasy does the same thing, just on many different consulting projects. One app, one exe used on many projects.



E.g. Contractor 1 (a consultant) is on project A at client One. He is the project manager there.

However, on project B, at Client Two he is just a reader, providing QA for the project.

And on project C, at client Three, he has no access at all.



I will provide a means for the user (Contrator 1 in example above) to switch between any of the projects they are assigned. When a project is selected, their role for that project will be set. (Based on a table that maps users to projects with certain roles (or maybe role sets...not sure until I know how this works a bit better)).



Does that make more sense?

Yes...that makes much more sense...What I would do in this case is create a dynamic permission key that is associated with each project.  All of the SF business object classes are in the MicroFour.StrataFrame.Security.BusinessObjects namespace and you can use them just as though you were writing your own SecurityDialog form. 

So when a new project is created I would create a new permission key:

Dim loPermission As New MicroFour.StrataFrame.Security.BusinessObjects.SFSPermissionsBO()

'-- Create a dynamic permission key
loPermission.Add()
loPermission.pm_Key = "Project 1 Key"
loPermission.pm_Description = "Dynamic permission key created at run-time."
loPermission.pm_BlockedAction = DeniedActions.Message
loPermission.pm_Category = "Client Projects"

'-- Save the permission key
loPermission.Save()

After the key exists, you can dynamically add this key to the user or modify it through the standard SecurityDialog window that comes with the framework.

Then when you need to test on the security key you would just do this:

Select Case SecurityBasics.CurrentUser.GetPermission("Project 1 Key").Action
            Case PermissionAction.Deny
            Case PermissionAction.Grant
            Case PermissionAction.ReadOnly
        End Select

Does that make sense?

Almost.



This seems to me that what you just suggested if there are different permissions for each project. That is cool, but not what I was needing.



The permissions are the same across projects. I.e. I might define the following permssions:



ProjectSetup - Allows project managers to setup project defaults

ProcessEditor - allows the user to edit processes (this is data managed by the app)

ManageMyProjects - allows user to change projects



They I might define the following roles:



ProjectManager - would have the ProjectSetup permission, ProcessEditor and ManageMyProjects permissions

ProjectEditor - would have the ProcessEditor and ManageMyProjects permissions

MyProjects - would have ManageMyProjects permission





Now, when Contractor 1 is working on Project A, I want to assign him the ProjectManager role and when working on Project B, the ProjectEditor role and on Project C, only the MyProjects role.



Permissions would be constant, based on feature set. Roles would be more fluid, but defined across all projects. User's assignment to a role would be based on which project they were currenlty working on.



So, I really need to have the ability to dynamically assign the current user to a specific role, one that is already defined for the application.

You will have to keep track of the roles assigned to each users on a per-project basis, then, right before the user logs into the system, you will need to change them to the appropriate role within the SFSUsersXRoles table so that they will be assigned the proper permissions.

So, essentially, you would be able to use the SecurityDialog to create the users and roles, and assign the permissions to the roles, but you will need your own editor to assign users to the roles for each project.  Then add/remove records to set the user to the appropriate role before the LoggedInUser.SetLoggedInUser() method is executed.

Yep, I was planning on tracking the user/role/project myself and on having an editor to assign users to roles based on project, so all of that is expected.



However, I will need to authenticate them, before I know who they are and can therefore determine what project they are working on (I also keep track of the last project they worked on, so I know what project to log them into at startup). Also, I will need to allow them to switch projects, without authenticating again. So, can I call SetLoggedInUser() separate from authentication? And can I call it independant of any authentication? I.e. it seems that what I need to do is authenticate the user, determine project and then role, update the SFUserXRoles table with the appropriate role for the project, the call SetLoggedInUser(). If I need to change projects, I would simply skip the authenticate step, but everything else would be the same, right?



Thanks for you quick replies to this.

OK, not so quick reply



I've been trying to figure out this stuff and it is a bit clearer, but I still have no idea how to actually do it. Basically I would like to do four things:



1. authenticate user (using SF security tables), look up there default project (in an app table, I can figure this out), lookup role they are assigned for this project (again my app tables, and I can do this), assign them that role (something about updating SFSXUserRoles table), then maybe some other action that makes this role take affect(??).



2. Allow the user to switch projects. They are already authenticated, just need to provide them a list of projects (this I can do), they pick one, lookup the role for that project, then back to assigning them that role and some action to make it take effect.



3. Allow user to logoff, then log back in, of course, this would include all the project stuff again



4. Lock app, so they have to reauthenticate to continue. Not sure how any open forms are handled here at all. Any info would be helpful as well as info on how to implement.



Sorry for being such a pest, but I'm on a tight schedule to see if this will work for this project (in this case, I'm talking about my own dev project, not one of the projects within the app...