Question:
I thought one of my users did not have access to open a document, yet she can. How come?
Answer:
- To find out, use the Admin | Access Analysis report.
When you run the report, you indicate the user whose access is to be evaluated and the object (folder, file, or document) to consider. You may have to run the report several times testing access to different things.
Setting up security for a system like Spitfire can be arduous, but we do have a fairly simple scheme that many of our clients use. Users can be divided into two camps: those that have access to generally everything, and those that do not (with the next obvious delineation being that some users have access to everything within certain project(s), but not every project).
Testing security comes into play when we think a certain user who is in the “have not” camp can “suddenly” see things somebody thinks he or she should not see. The good news is that we have yet to find any bugs in our security code—but drawing the picture of why things are doing exactly what they should do can be time consuming without this report.
An example: Assume a user (let’s call him Nick) with very limited access has access to a file in the Catalog and you want to know why. The system is designed to give inferred access. Nick can’t see much of anything, but if you route him a document, the system infers you want him to have access to it. So routing a document to someone grants access to that person. If there are attachments on the document then Nick can see those attachments, regardless of where they are in the Catalog. Routing aside, Nick can get access from his roles, and sometimes those roles are broader than the implementer realized.
Here is some sample output for a System Admin with full access. In the sample below the variables have been highlighted and explanations are added under each line:
Access evaluation for Demo Employee
to file EN123000
in folder /General/Time Cards
The above three lines identify who (Demo Employee) is trying to access what (a specific file in a folder)
Generally, the user has access
This line indicates the user does have access; the remainder of the output tries to explain why.
context type: Timecard
context project:
context ref: Misc
The above three lines identify attributes of the file that contribute to security tests.
The user has access based upon the folder
This line says the user could access the file just because of its location, i.e., the user has access to the location.
– permit context: all types, All Projects, any Ref
The line above could repeat, once for each “reason” the user has access to the location.
User has access thru Doc – Sean P. Alexander, Week Ending 01312004 (#0000010110)
This line says the user could access the file just because it is attached to a document that the user can access.
This line could repeat, once for each such document.
Analysis of access to Doc – Sean P. Alexander, Week Ending 01312004 (#0000010110)
Having answered the question about access through a document, the report continues and explains why the user can access ONE of the documents listed above (in this case, there was only one listed).
The user has access to document because it is routed to them
This line says the user could access the document because it is routed to them.
Document Context – Type: Timecard
– Project:
– Ref: Misc
The above three lines identify attributes of the document that contribute to security tests.
User has access to document thru role: System Admin, any type, any project, any ref
User has access to document thru role: Everyone, any type, any project, any ref
User has access to document thru role: Project Manager, any type, any project, any ref
These lines say the user could access the document because the user is in the listed role that matches the security context. These lines could repeat, once for each such permit.
Additional Comments:
The report uses a stored procedure – rq_WhyCanUserSeeIt. Some may find using the report provides greater flexibility. The most common security ‘mistake‘ is to place users into a role that grants READ access to every document (or every document in a project). Once the user has read access to every document he or she gains (by inference) read access to every file attached to any document. Sometimes this outcome is not what was intended or anticipated.
KBA-01212; Last updated: November 8, 2016 at 12:07 pm;
Keywords: permission, roles, Access Analysis report