Do you remember the company “Business Layers”? It was among the 1st who implemented a user provisioning software, called “day one”. What a perfect name for a company! Expressing their very business purpose - to promote privilege assignment from the technical level one level up to the business layer – in their corporate name. But later they successfully sold to Netegrity who successfully sold to CA who put all into a big melting pot and not much of the original ideas and products remained.
Last Sunday while jogging though the quiet very early morning Hamburg this company came into my mind again when I was suddenly missing – well – the business layer.
To explain it a bit more in-depth let’s have a look at the NIST original RBAC definition:
Here the roles are introduced as an abstraction of the users who might be – no, typically are – different individuals whereas the role, which is tied to a list of resources, might stay unchanged. Hereby the role factors out the commonality of the individuals with respect to the permission assignment. As the RABAC concept is widely known and even mostly understood there is no need to further explain, that roles can be assigned temporarily on session basis and can themselves be ordered in a hierarchy. Permissions by RBAC are defined as ‘operations on objects’, equivalent to ‘actions on resources’ and so on.
These resources however are the real physical resources. So they are not ERP-system or ERP-system.general_ledger or or ERP-system.general_ledger.accounts_payable but SAP FI or JD Edwards EnterpriseOne.GL or Microsoft Dynamics NAV.genel.accpay. Whereas the corporation on the business layer simply has defined that this role should have read-/write-access to the accounts payables.
So at this side of the equation an abstraction is missing too. Like the role abstracts the individual (represented by the digital identity) some ‘generic resource’ should abstract the ‘real physical resource’. By this intermediate layer we could reduce the necessary number of roles and hence reduce overall complexity.
And allow business people to model roles on the business layer.
O.K., how now should we call this new object? Generic object, virtual object, abstract object? Hmmm … but what is your opinion? Can you eventually follow and agree to my esoteric thoughts?
Last Sunday while jogging though the quiet very early morning Hamburg this company came into my mind again when I was suddenly missing – well – the business layer.
To explain it a bit more in-depth let’s have a look at the NIST original RBAC definition:
(Source: Ferraiolo, Sandhu, Gavrila: A Proposed Standard for Role-Based Access Control, 2000) |
These resources however are the real physical resources. So they are not ERP-system or ERP-system.general_ledger or or ERP-system.general_ledger.accounts_payable but SAP FI or JD Edwards EnterpriseOne.GL or Microsoft Dynamics NAV.genel.accpay. Whereas the corporation on the business layer simply has defined that this role should have read-/write-access to the accounts payables.
So at this side of the equation an abstraction is missing too. Like the role abstracts the individual (represented by the digital identity) some ‘generic resource’ should abstract the ‘real physical resource’. By this intermediate layer we could reduce the necessary number of roles and hence reduce overall complexity.
And allow business people to model roles on the business layer.
O.K., how now should we call this new object? Generic object, virtual object, abstract object? Hmmm … but what is your opinion? Can you eventually follow and agree to my esoteric thoughts?
No comments:
Post a Comment