Designing an RBAC Menu

[ytene]

Hello Everyone,

I apologise in advance for the length of this post, especially as this is my first technical post [so please be gentle!]. if I can I'd like to ask for some help and/or advice with respect to building a Form that can be used to render a dynamically-changing menu for a user. This needs to be a little bit more sophisticated [but similar in principle] to the "Switchboard" variant that was offered with Access in older releases [i.e. 2007]. [ I am using 2013].

I enclose below some context on the outcome I'm hoping to achieve...

My Access App can authenticate users [simple auto-launch form] at opening. Using a very simple set of related tables [ A user may map to one or more Roles, each of which can map to one or More ACL objects. An ACL object, in this context, then maps to a "Menu Option", which manifests as a record in a Menu Table]. Through this model I can define different roles within my Application that I want to have differing levels of access to functionality through my Menu system.

I had envisioned a simple form with [for example] up to 20 dynamic "button" objects. Each button could be re-labelled [with Menu Description Information, from the Menu Table]. As a result, the "rendering" of a menu would take in 2 key items - one would be the Menu Node [i.e. where are we in the menu structure?] and the other would be the Role ID [i.e. which options from the available list is this User/Role able to "see" on this menu? A Proc could then iterate through some form of Array object [of buttons] and update their attributes with elements from a result set from the Menu table... which itself could be implicitly filtered by means of a join with the ACL and Role tables...

So to the problem...

I am looking for guidance and advice on an approach that would allow me to:-

1. re-enter the form as often as needed, carrying over a global-variable identifier to help the program identify which node of the menu it is supposed to be displaying

2. grab the relevant menu options from the Menu table [dead easy - select "* WHERE menuParent = " {the correct node ID}...

3. filter the result set based on the Role of the Authenticated User [basically a table join; again I am expecting this to be very straightforward]

4. rendering a series of buttons on a Form, with each button dynamically populated with a Menu Item Description that will change as the user navigates through the application... For what it's worth, I figure that handling user choice in this scenario is pretty easy: even though I may change the label of a button, I can set each button to perform the same action [i.e. call a subroutine that assigns a specific value to a working variable] and then jump into some dispatcher logic which figures out what to do based on which button was pushed...

The tricks are:-

1. I'd like to label the buttons dynamically, using content from the "Menu" table
2. I'd like to selectively render buttons, using most likely a join between my "Menu" table and an "ACL" Table that is itself joined to a "Role" table...
3. It is likely self-evident, but I will need a "back" capability, which should be easy as this will typically be a jump "up" the hierarchy to the parent node, but it might be nice to lay out a "breadcrumb trail" along the top of the Menu form, if such a thing is possible?
4. I am entirely happy if the rendering involves using "Visible=false" to "hide" one or more inactive/impermissible menu options, thus leaving "gaps" in the menu structure... [ In fact this might be nice...]

I'll stop with the explanation here, as I've already written far too much [thanks for reading this far]. I'm not wedded to any particular solution, but as I am very much a novice, will strive for simplicity if it is at all possible...

Thanks in advance for any responses!

 

[spikepl]

1. What is RBAC ? DO not use abbreviations!

2. To be honest, your request is full of details that are difficult to fathom at this stage, and it is not supported by any graphic which might have rendered it more digestible. Make a sketch

3. Your narrative gets lost in some happy mix of minutiae and major things. I'd suggest you identify major issues if you have any, and otherwise make a mock-up for us to scorn and heap abuse upon. What I mean is keep stuff simple. Oh yeah - and ask for specifics (for guidance I'd recommend the teachings of Buddha)! That makes it so much easier to help instead of having to guess what is required.

 

[jdraw]

Can you give us some background on the database and related business that you are dealing with? You seem to be focused on a "dynamically changing labels" and with only 2 posts in the forum, it seems a little mis-directed.

There are several papers (many theoretical) on RBAC. It appears that you have been researching the topic.
Have you really got your tables and interfaces designed and tested sufficiently to apply RBAC? If so, you have done more design effort than most.

 

[ytene]

Spike,

Thank you for responding. I am sorry that my initial post was not clear. As jdraw correctly surmised, RBAC = Role-Based Access Control.

I like your suggestion of a mock-up, but unfortunately this forum is configured to prohibit me from providing links to images until I have made at least 10 posts... Sorry, I shall have to get busy with posting...

In another attempt to describe what I would like to happen, here's a walk-through from the end user perspective...

A user opens an Access database and is presented with a Form on which they are asked to provide a UserID and Password. The ID enables retrieval of the User's record from a User table... The on-screen password is then converted to a SHA1 hash and compared with the copy in their record. If there is a match they are authenticated to the application. [I have this working now].

Once authenticated, the user is presented with a menu Form. Because the system can determine from a table that the user has a specific role [i.e. Reporting] then they are only permitted to see menu options that relate to report generation. Let's suppose that the other Options on the "Top Level" menu cover things like "Enquiries", "Update Data", "Administration" and so on. [ In fact, the idea here is to build a generic, flexible menu system that can be extended to represent anything, just by changing the contents in the Menu table... But with my example, the *only* option this user would see would be, for example, "3. Reporting" [i.e. the third option].

In our example, if the user clicks on Button 3 [Reporting], then a "new" Menu would be presented, this time with new content on the buttons. The new content would offer a different selection of Reports that the user could run. Of course, by "new" I mean that it would be the same underlying Access form, but with the titles and functionality of the on-form buttons changed, dynamically, to show all the reports that the user was entitled to run...

By building this on a data structure, instead of hard coding, I basically get both a navigation and a security system rolled into one...

Thanks in advance for your Buddha-like patience. How am I doing with my explanation???

 

[ytene]

JDraw,

Thanks for responding... I'll do my best to give you some more context...

This database/application is basically a combination of "reference library" and "quality control" for a set of very specific technology requirements. Basically it is intended to contain 3 discrete types of operational data:-

1. Industry Standards, starting with the NIST Cybersecurity Framework [CSF] and the reference sources [i.e. COBIT 5, ISO27000, NIST SP800-53r4] that it references. So the first thing that the database does [and this is complete already] is take all of that textual data, break it out into individual data elements, then creates links to tie all the related data elements together. This is complete...

2. Our Control Requirements. We also have our own reference material [about 1000 individual security objectives] that also need to be broken down. We are then able to map between the industry standards and our internal Controls.

3. Our Application Inventory - a simple table listing all our applications...

4. Exception Data. Finally, if we have examples where we have either known issues [for example, we have run a penetration test and spotted a vulnerability in an application], we get a formatted report in electronic form that we can import and upload into this database. We then track work done to fix the issue...


So... We expect a range of different people to have access to this database/application, but we need to be able to restrict access on a need-to-know basis to tightly control what people can see or do. For example, even if you are a programmer responsible for fixing vulnerabilities in *your* application, you must not be permitted to see vulnerabilities any any *other* application. Or, if your role is to import new vulnerability data, you must have access to the scripted import function, but not be able to see the data, and so on.

If we think about the different types of role we want to have accessing this system, then we can identify the following:-

1. Master Admin - super-user level access
2. user Admin - a couple of staff who can create new accounts in the system and assign them to roles.
3. Role Admin - two *different* staff who can create profiles in the system such that different communities of users can access functionality and the data it contains
4. Developer - users who can access the system review all the Control Objective and industry standard data, plus they can access and update information relating to vulnerabilities found within their applications.
5. Vulnerability Management - users who can access the system and refresh the details of detected vulnerabilities as new reports are produced. These users *cannot* get details of the application containing the vulnerability, nor see progress on any in-flight fix
6. Auditor - users who can examine the data broadly, without limitations, but cannot update anything...
7. etc...

To make this work - and perhaps equally importantly, to enable us to re-use this configuration effort elsewhere - we are attempting to structure the application into a modular form, with associated functions grouped. We can access them from a series of sub-menus, subordinate to the "Main" menu.

So far, I have written, tested, and got to work:-

1. All the "static" data, uploading and cross-referencing...
2. The basic data imports [our Applications, vulnerability data, etc]
3. Report generation [various different reports]

I am now in the process of trying to tie it together through some dynamic menus. The good news is that all the RBAC stuff - i.e. defining roles and permissions, and also a data structure that converts into a menu hierarchy - I have done before and have ready to go. Pretty much the only bit I am missing is the ability to create a set of Access Forms with a series of click-able buttons, but done in such a way that I can determine, at run time, which buttons are visible/usable and which are not... Now, I have the data structure that can render the menus, I just need to figure out how best to "present" it in an Access Form....

How am I doing with the explanations?

 

[jdraw]

Your explanations are encouraging. I remember dealing with some of this on a forum in the last year or so.
What led to a decision to do this in Access? Will this be a web application?

Have you got the range of roles covered?
One concern is that all users, regardless of role, must only access the database via your application/interfaces.

I did find a small model (attached) that may be of some value to you. I didn't create it, I found it somewhere and downloaded it.

Good luck with your project.

 

[ytene]

JDraw,

Thanks... In terms of the roles it may be a little early to say. However, with the approach that we're taking, this system should lend itself to be extended as required. [ More importantly, if the approach works, we can lift/drop for other similar requirements, since it is intended to give us a menu that adapts, dynamically, to the user authenticated to the system.]

In terms of limiting user routes to the data to only our defined interfaces, [applications] then I completely agree with you. At the moment we are prototyping in Access, with an Access front end. If we stick with Access we will likely produce a runtime-only edition, for that reason. However, I am aware that Access 2013 is designed to integrate well with Sharepoint and to become a development platform for "Web Apps" by allowing a designed Access DB to be uploaded. We are certainly bearing that in mind; it is factored into the design. The only thing we anticipate needing to change may be the authentication mechanism, since of course Sharepoint would handle that via it's Single Sign-On [SSO] capability.

The RBAC model you listed is good - thanks for sharing. It is pretty much exactly what our basic [V1] solution will look like. [We won't implement the Session table for Access, since we don't need to persist that across commits]. Of much more interest to me for the V2 piece is the "data aware" requirement for security...

Put another way: if you are a Developer accessing this system I need to give you access to *features* based on your role as a developer. This means that you will be able to see vulnerability detail, and to update a tracking log covering work you do to address the issue. *However*, at the same time we need to ensure that you can only see hose vulnerabilities for applications that you personally are responsible, not those aligned with different developers. We need to do this by accessing elements [fields] in tables within the "Application" register, looking for your ID [we are using a common ID field, so at least have no translation/lookup issues] and then returning a result set that *only* matches Applications for which the requestor is identified as the Developer...

Now... there is an easy way and a hard way to do that. The easy way is to "code down" to the explicit Application detail and the table with relevant elements. The problem with that approach is that it would be a bespoke solution that would need to be re-written if ever we have to apply anything similar elsewhere... The better but harder approach is to abstract from the "Application specific" data, either by writing a software interface to rebuild the data on import [so that it goes through a simple transformation as it is imported or referenced] or to create a data linkage that can be automatically populated. obviously we favour the latter approach. We've looked at the data structures available and it will work for this specific implementation, but we will do our best to write something that is "implementation-neutral".

If I can get this pesky menu implemented in a simple way, that is...