Protection Rules Help

kklosson

My app has multiple accounts. Within each account, I have Candidates and Investigators, each having the same AccountID (called Organization.ID).

The protection rule is that an Investigator should not be able to view a Candidate in any account but his own. Through the visual perspective, he can't but I need to set protection for workarounds. The rule is:

If LoggedInInvestigator.ID IS DEFINED AND Candidate.Organization.ID<>LoggedInInvestigator.Organization.ID Then
READ PROTECT Candidate FROM Investigator

I test this by giving the Investigator the standard Search Objects menu item. When searching Candidates, the Investigator sees all Candidates in the system.

What might I be doing wrong here?

kklosson

And btw, this rule is attached to the Candidate object.

RentProperty

Hi Kingsley,

I Think there is nothing wrong with the logic but I don't think AIM allows this. You can only use the PROTECT RULES with attributes specified on the object itself. For instance it would allow you to say for instance:

IF Candidate.Status='Past' THEN READ PROTECT CANDIDATE From Investigator.

Support, is my interpretation correct?

Kind Regards

Hein

kklosson

Thanks. According to Docs, I cannot protect a reference attribute, but I believe this should be allowed.

bucobill

If you are doing a query for an object you could try to add an attribute of investigator and candidate. The not allow access to forms or queries based on these attributes. It may help or it may be too much work but it is a solution we used for managers of the company and managers of the customer.

Powerm

To avoid workarounds I always create separate different access levels AND different queries and forms for each access levels. It might be more work but it is much safer.

kklosson

Thanks all but my point has been missed, I think. My app provides all of the necessary logic to control access all objects. My concern is that a malicious user can interrupt and forward commands to access objects in other accounts. So to test, I temporarily include a Search function in the user's menu and use it to query objects. When my protect statements work, they work fine and the user is READ PROTECTED appropriately. But the protect statement referenced above is apparently not allowed.

So my problem is that I want to prohibit an Investigator in one account from reading Investigators in another account. They both have a different Investigator.Organization.ID.

I can't seem to do it.

Powerm

If you want people to not look at other people's account to have to assign an Investigator to each Case. Once this done you can add the following filter to your Queries or Form :

Case.Investigator.LoginName=LoggedInSystemUser.LoginName

kklosson

Thanks, but again, within the application I have no problem constraining queries as needed. This is a higher level security issue. It is always possible for any user to intercept the transmission to the server, change it, and forward it on. This enables a user to escape from the provided logic and perform queries while remaining within the scope of the AwareIM application.

Example: Investigator logs in. Within the app, he/she will only ever see candidates within their own account. But using some very basic intercept techniques, they can intercept a query. The query could be:

FIND Candidate WHERE Candidate.Organization.ID=LoggedInInvestigator.Organization.ID

They intercept it and change it to:

FIND Candidate

Now they get all candidates. This is where protection rules are needed the most. The application logic works find, but a slightly sophisticated user can get past it. If the object is READ PROTECTED, then they won't see it using this technique.

Powerm

Well....if the Investigator starts to try to hack the queries you might have a problem 🙂 In one side you should have a strong READ PROTECT rule and as well an other rule logging all the changes on the BO and firing-up an alarm when someone is being to curious....

kklosson

Yes. I agree with all of that. This is why I am trying to create an appropriate READ PROTECT rule.

kklosson

Got it. I often get confused between object names and access levels. In my case, I was logging in as an Investigator with "Manager" access level. Hence, could not see a valid result. Turned out READ PROTECT from ALL was what I needed anyway...