That was our first attempt, that enterprise users have access to all roles within all projects. Unfortunately, that is not the case. Think of it really as more there are enterprise roles and project roles. Enterprise roles are for data that is defined as an enterprise level. Most would only be able to see the data, a few would be charged with maintaining it. A user could actually have both kinds of roles. I.e. they have project level access for project level data, but they also happen to be an expert in some enterprise area and have an enterprise role for that one area. E.g.



Bill is an expert with the Acme Process Certification, which is used to certify a process as meeting a set of standards. Entering and editing standards data is an enterprise level role and Bill has this role, so he can maintain the Acme Process Certification standards.



However, Bill also works on projects, helping clients define processes. In this case, his role related to entering/editing processes (and his access to any project) is defined by project. He might be working on 1 or maybe two projects at a time, so he has access to those two projects.



BTW, I have a working system to handle this now. I'm using a custom login form, that calls a custom class that handles the details. The original question of this post was how to determine if a user had a specific permission when they are not yet the logged on user and the answer to that is to authenticate them, which returns a user BO, which can be used to create a LoggedInUser, which can be used to check a permission.



Thanks for the help and suggestions. I'm always looking for ways to make it simpler...it those darned users who are making this complicated!

I'm not an expert in the code for security, but let me ask if this is a valid approach:

Objective: User attempts to login (UserID/Password? or Windows Authentication). If successfully authenticated, then the system will retrieve the projects and roles within those projects for which they are authorised.

Assumptions:

1. All Users must be authenticated before the application attempts to retrieve their roles.
2. There are two classes of users - Enterprise Users who have access to all projects and Project Users who have access only to one or more projects. Question: Does the Enterprise User have access to all roles within every project?

It seems to me that you would setup Project and Role tables (Enterprise Project would be null or a specifically defined value). In your login code, the User Roles would be retrieved.

As Trent suggested, keep it simple and remember that all users must be authenticated before the roles are retrieved.

Regards,

Flavelle

But as I understand your security, you don't have the native (i.e. easy) ability to define a set of roles based on some application data element (in my case, some user's roles are defined by the project they are working on).







The application tracks a default project, which is the project that is used when they login.







Er, I thought I was As soon I know who they are (they have been authenticated), I have to figure out if they are 'enterprise' users or 'project' users, which will determine if their roles need to be changed. In all cases I need to figure out their default project, so I can setup the 'context' for the application.







Huh? I'm associating projects to users (remember, 'project' is an in application term, describing data within that application, not a VS project), or if you prefer users to projects. It is a linking table (userID, projectID).







I'm all ears, But here is what I'm dealing with:



1. Two basic classes of users: those who have access to all projects and those whose access is determined by project.

2. For users who have access determined by the project, I will need to dynamically set the access based on project.

3. In SF (as I understand it), I must set the roles for a user before they are logged on.

So going back to my previous post, does the user have to select a project or does it just know somehow which project to open?

There is a class of users that have enterprise level access. I.e. they can access all projects because they are 'enterprise' level users. They might be executives, users in a departments who help all projects or provide QC on projects.

Yes, it may work fine...but I woudl still consider revising the approach you are taking.

Greg,

I think this whole think has become much more complicated than it needs to be.  If it were me, I would adjust application to work within the confines of the security so I would not have to make a lot of changes.

For example, when a user comes into the application, they are going to have to choose which project to work on, right?  Why not do something with security at that point.  Or what if your projects allows certain users to associated with it, rather than trying to go the other way around. 

I don't know your application, but I do know that we can come up with a more simple solution that what you have been doing lately.  When it starts getting complicated like this...we always sit down as a team and figure out another avenue to travel.

In poking around in the Object Browser, I'm wondering if this might work:



' Authenticate user

dim userInfo as SFSUsersBO

dim loginResult as MircoFour.StrataFrame.Security.LoginResult

loginResult = MircoFour.StrataFrame.Security.Login.AuthenticateUser(me.txtUser,me.txtPwd,"",userInfo)



' Create temporary logged in user so we can check to see if they have all project access

dim tempUser as New LoggedInUser

tempUser = MircoFour.StrataFrame.Security.LoggedInUser.CreateNew(userInfo)

If tempUser.CheckPermission("AllProjectAccess").Action = PermissionAction.Deny Then

' Do role setting stuff

End If



Me.OnAttemptLogin()

Is the "Enterprise" user static or change with the project?

Well, what you originally suggested (as I understood it) was to use a custom login form, then use the AuthenticateUser to see if the user was OK, then do my custom work to figure out what role(s) the user has for their 'default' project, load those roles into the SFSUserXRolesBO (clear any previous roles), then log them by calling the OnAttemptLogin(), which would handle logging them in, deal with invalid logins, etc.



I suppose that would have worked, except I actually have two classes of users, those with access to all projects and those with access on a project by project basis. If I have to go through the SFS BOs, I suppose I have to look at SFSRoleXUsers, SFSRolesXPermissions, SFSUserXPermissons all to figure out a permission right?