I'm developing an application to store and manage files, passwords, things like that. Currently I'm thinking about how to handle access to this data (since it may be the case that you don't want anyone being able to view these things); my initial thought was a "security level" system; every user has a security level (given by an administrator), which is actually just a number between 0 and X. When uploading files, storing passwords, etc. you can specify the required security level. For example: user X has a security level of 10 - hence he can look at all data which requirements are equal or lower than 10. Every data with a security level requirement above this won't show up.

My concerns here are: it could get tricky if you have a lot of different security levels. At some point the administrator is probably like "well, what security level does this need to be viewable by managers but not for senior developers? 50? 100?". Kind of a solution to this problem would be to store security levels by name. So you could manage security levels by value and by name; e.g. security level 1 is "Intern", security level 10 is "Employee", 20 is "Accountant", etc.. That would mean you're not assigning the security level itself to a file (or a password, or whatever) but a readable string. Sounds easier - but is still the same as above.

I don't want to handle every users access individually. That would be way to much work when, for example, just want to provide a file which shouldn't be read by new employees but anyone else.

Any other ideas? Or are my concerns about the security level system just exaggerated and it's actually "okay" to do it that way?

  • Sounds more like you need to give individual permissions to specific people, could you confirm or correct me please? Aug 19, 2017 at 18:14

4 Answers 4


Using a CRUD approach

Instead of assigning classifications like "intern" or "accountant" to a user I would assign them to the data and then give each user Create, Read, Update, Delete for the various types of data.

  • Few users should have access to "Authentication" data (passwords, etc)
  • A few more might have access to "Personally Identifiable" data (contact info, medical data, etc)
  • Everyone can at least Read "Public" data

This matrix can still become pretty complex so each classification of data should represent a clear division before adding a new one.

The benefit to the user is how clearly this system communicates what they can do (Create, Read, Update, Delete) for each kind of data/file


Use a Security Matrix

Building on Dave's answer above, I'd recommend implementing a security access matrix feature where users are in one or many groups/roles.

Example below is based on a development team.

'Base' group - allows read access to most objects. If someone isn't in the 'Base' group, they can't see anything.

'Developer' group - allows create/update access to a number of tables (work items, for example)

'Senior Developer' group - allows creation/update access to other tables (code reviews, task assignments)

'Development Team Lead' group - allows creation/update of high level project stream tables and lists of tasks

'Project Manager' group - allows creation/update of projects and time-tracking codes

So, a Developer would be in Base and Developer
A Senior developer would be in Base, Developer, and Senior Developer
A Development Team Lead would be in Base, Developer, Senior Developer, and Development Team Lead
A Project Manager would be in Base, and Project Manager

So, the matrix would be additive in nature. Each group that you're adding people into enables a specific set of functionality. It's also easy to change people between groups.

What you don't want to be doing is tying access roles to specific people, this quickly gets confusing and unmanageable.


This seems like a requirements issue... before you know what kind of system you need to put in place, you should probably know how many levels of security are required.

As far as levels of security/permission, having different levels of access for different users is sensible and common. I don't know about a numbering system as you describe, but that seems as if it might make sense, but this will require not only that each user be given a security level, but that every piece of content you have will need to be categorized, which could be a very big job (and different people might have very different ideas about the level of access people should have to certain items).

One way you could do it is by automatically assigning users a level of whatever sort when they are created in the system - perhaps based on their title, place in the org., whatever. Once they have a level assigned, access to different data can be granted by either individual piece of data or by "folder," groupings of pieces of content. So a user with security level 4 or type "author" might have read-write-comment access to every piece of content in a given folder, while a level 3 or "commenter" user might only have read-comment, and level 2 or "viewer" might only have read permission.

By default, anything placed in that folder would inherit the permission settings, so you would not need to assign permissions manually to everything. You could, of course, assign them to individual files or to whole folders of files if you wanted to, but granting access by folder/directory would mirror the structure of many file systems and OS security settings

This is a huge topic, of course, but it is pretty well-trodden territory for PC operating systems. Take a look at how Windows and Mac OS deal with these things as a starting point:



You might also look at this other thread:

Permissions and roles

  • Thanks for your answer. Your approach by assigning a level at user creation is already considered; we're talking about a project management application, where every user gets his very own level when created - but levels can differ from project to project. That was my idea at least. I'll take a look at these links the next days, thanks.
    – nehalist
    Sep 23, 2016 at 9:51

In my experience from banking and pharma, the restrictions are often horizontal - people in a department need access to "their" sensitive documents.

E.g. HR guys have access to reports about salaries, doctors to private patient stuff, personal bankers to presentations about a client's portfolio... CEO does not need access to everything (regulations might even forbid that). Also developers working on project 1 do not have access to project 2...

Since people come, move, and leave, any system with it's own custom access management will get hard to maintain over time. The only long-term working solution I've seen is a centralized system for user management, such as LDAP and/or its Windows extension Active Directory:

  • assign users to groups, groups to bigger groups
  • assign documents to groups, inherit from folder properties
  • keep everything up to date
  • have an easy procedure to request access (and removal of access)
  • have automatic group assignment based on department where people currently belong (import from other system if LDAP is not the single source of truth about department hierarchy)

Ideally if that comes with a Single Sign On implementation so users don't have to (mis)type their password 20 times per day.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.