This image represents how we handle functional roles in our access control system. A functional role is a set of accesses created to simplify the provisioning/deprovisioning process such that a resource need only submit a single request for access to all applications, platforms, roles and resources provided within the collection. It is “functional” in the sense that the aggregation of access is typical for the employee’s role within the organization.
The entities with “Functional Role” in them define the available access within the role. It’s the template of the role (much like a class definition in object oriented programming (OOP)), not the instantiation of the access (i.e., not the instantiated object in OOP).
Some points to note:
- An employee (resource) is granted access to a Role, and a FunctionalRoleVersion (FRV) is a role.
- FRV’s also contain zero to many (0…n) roles, which is represented by Functional Role Application Access.
- FRV’s may also contain 0…n account types (a Functional Role Account is a Account Type). For simplicity’s sake, an account type essentially represents platform roles such as Active Directory and DB (MSSQL, MySQL, etc.) accounts.
- VersionNumber is included as an attribute in Functional Role Version. The table also has an incremental surrogate key.
Any ideas on how to model this in a raw vault such that:
- the source system can be “regenerated”?
- it is fully auditable?
I have been wrestling with this for a while and have ideas of my own. I’m interested in other people’s perspectives and opinions, given the tiny background from above.
Thank you.
Maybe share a DV model you’re think of for this?
This is my initial crack at it.
I struggle with whether or not to include hierarchical links. They would exist for:
- Functional Roles - They are applications in the system and also contain applications
- Function Role Versions - They are roles in the system and also contain roles, which themselves are associated to applications. Roles cannot exist independently of an application.
The hubs without satellites in the diagram are existing hubs in the DV. Those satellites are non-essential to this particular model.
I’ll take a look when I’m back from PTO
Of course this is an attempt to use DV patterns to model the role, functional role, frv and hierarchies! Not so much about modelling/mapping the business!
Without knowing what the data looks like if the above model you propose supports what you want to do then why not! I did something similar for a JIRA Vault and included a jira_id column in the actual raw vault so if you wanted to tie the RV/BV with business data to a JIRA and its history you could.
I have also modelled Snowflake custom role hierarchy using DV templates, I knew what I wanted out of it and how I wanted to map that to what I was doing in my DV
You your Q’s
- the source system can be “regenerated”?
- it is fully auditable?
Yes to both, the second implies that I can do the first. As long as you stick to historizing your attributes in satellite tables I think this should be fine.
Thank you, @patrickcuba .
That’s my primary struggle here. As far as we know, being in the business and having interviewed stakeholders, no other system in our business captures this kind of information. Thus, it’s extremely easy and tempting to model this as a source system DV. We are still integrating it into the big picture, though.
I appreciate you coming back and taking the time to respond after your PTO. I hope all went well for you at the Snowflake conference/summit/whatever-it-was. 
Hello Nicruzer!
Your model cannot regernerate if any hub combination in the links gets deleted in the source system.
