How to implement shared access to objects by group?

gerber1

I have an application where I use Creator: full access to limit access to several objects. This all works fine. Objects are appropriately filtered in queries, etc. Our users are organized by office. All users in a particular office share the same objects. To make this work, they all use the same credentials to log into the application. Otherwise, they would not be able to see each other’s entries. Users from other offices, which are separate businesses, must not be able to see objects created by users in other offices.

Now, I have the need to keep track of which user from a given office is actually using the system. One option is of course to build security from scratch. However, I believe it should not be as hard as that. Here are a few possible implementations that I am considering. There are questions regarding AwareIM for which I need answers, so I may undertake the process of implementing this.

1) I’ll call this first option the impersonation scheme. The user would login with their own personal credentials. Once they log in, the system would save somewhere the LoggedInRegularUser who actually logged in, look up the office–specific LoginUser connected with their office in an appropriate structure (link table, for example) and then do an impersonation by switching the LoggedInRegularUser pointer to the appropriate office-specific RegularUser. All activity subsequent to the impersonation would be handled as it currently is. However, we would be able to track the actual person who logged into the system when we need that.

Question: Is there a way in AwareIM to engage an impersonation as described? If not, is this something that could be added? I know that avoiding impersonation is usually the goal, but there are many reasons for such capability as you already know.

2) The second option would require support for groups of users in AwareIM. Rather than having an office–specific login, each user would have their own login, there would be no impersonation, and a construct connecting all the users from an office (a group) would be defined and populated. Then when AwareIM constructs a query to retrieve objects where AccessLevel is set to Creator: full access, the query would include a join so that objects with LoginName set to any of the users in the group for that office would be retrieved.

Question: Is there any functionality like this built into AwareIM that can be exposed for this feature? Alternatively, what is the feasibility of creating such capability? Do other users consider this a worthwhile feature? I realize that this is the least likely solution to be possible, but it seems to be the most broadly useful.

3) The third option would be to create a new application, the purpose of which is solely to login a user, look up the office-specific login to the system, which would be stored there, and submit a URL string logging them in using that office-specific login. Ideally, a parameter could be passed in to identify the actual person to the system, which could be used as in option 1 above.

Question: Is it feasible to submit a constructed URL string in the way suggested above? Would such a submission be secure if using SSL? We would create a way of reproducing the un-hashed password to the office-specific account of course.

I would really appreciate any experience from the group or Support to help me achieve this capability without having to go everywhere in the system and implement my own filters.

Thanks in advance,

Roy

P.S., I am using 5.1a (1441)

tford

Roy,

What you are trying to accomplish is pretty simple in AwareIM .. much simpler than the options you described.

Assuming all BO instances have an Office indicator stored in an attribute, you can simply use rules to do this.

1) Each user would have RegularUser.Office attribute

2) Each BO you need to hide would have BO.Office attribute.

3) Rule on BO from #2 above to hide instances not from user's office:

IF BO.Office<>LoggedInRegularUser.Office
READ PROTECT BO FROM ....

You should also consider upgrading to the latest version / build. There were lots of new features added since build 1441 that give the configurator the ability to use LoggedInRegularUser attributes to control menu items & the like.

gerber1

Thanks Tom.

I really have not utilized READ PROTECT yet, so I have not studied how that is stored in the database yet. Anyway, that may be a good solution.

A couple of thoughts:

If I add a new user to an office, I assume they will not be included unless the READ PROTECT is itself implemented as a rule rather than a data construct. If the latter, I will need to adjust the data supporting the READ PROTECT to enable access for the new user.

If a user moves between offices, which should be rare, the same concern could apply, again unless the READ PROTECT is implemented as a rule... In this case, they would need to become excluded from objects of their old office and enabled for the new one.

Thanks again,

Roy

tford

Roy,

The scenario I described would easily handle both new users & transfer of a user to a new office. A user with appropriate security clearance would simple record the Office value for the user.

gerber1

I forgot to come back and thank you, Tom. I had to unwire all of the "Creator: full access" setup, with side effects related to the system dropping LoginName, etc. but it worked great.

FYI, I had not previously used READ PROTECT and had a misconception about how the rules worked for it. These rules, while they are exercised when a creation or update occurs, are not executed, per se, making them fundamentally different, in my mind at least, from the other rules with which they are grouped. They might better fit within a new tree node under "Business objects" called "Rules (when object is read)".

In a hasty look at the feature years ago, I tried to imagine what some executing code would do to enforce read filtering, and how that would be implemented was not something I was interested in seeing. That's why I did not study it further at that time.

Support: I suggest grouping any READ PROTECT rules under a separate tree node under Business objects such as "Rules (when object is read)" and not grouping them with create/modify or delete rules.

Thanks,

Roy Gerber

tford

Good point Roy. Had not thought about READ PROTECT in that way.