by André Koot
I’m not sure when I heard it first. It must have been a while back, but it still seems a valid statement. Accountability, the mandate and responsibility of an owner, is not an easy to grasp concept. Or rather: easy to grasp, hard to realize. Ask any professional if he or she wants to be accountable, and the answer is most probably No: For the candidate it’s not clear what accountability means (both positive and negative) and what the consequences will be in the end. And if someone is only hesitant, the next question will be: what’s my mandate? And that’s just logical: accountability and ownership need a mandate because one has to be able to enforce the accountability responsibilities.
In most IAM programs we try to find owners, who are accountable for access control decisions, like defining SoD rules and responding to access requests from self-service portal users. It’s a daunting task to find any business owner, a person with the mandate to make access control decisions. And you will probably agree with my finding that without a business owner, any IAM program is doomed…
And then, in any RBAC project, one of the deliverables is appointing Role Owners. And that’s odd. What is a role owner?
In RBAC the core concept is to define a business role or application role. The role connects user accounts to entitlements. For instance, the business role of Accounts Receivable contains the entitlements, or permissions, to application functions and resources in one or more platforms or services. Then, when the AR role is assigned to a person, the corresponding entitlements are granted automatically. The role owner is the responsible party for maintaining the contents of the role and changing the role’s entitlements if required by relevant stakeholders.
Yes, that’s odd. The role owner is not accountable for the role content. The role owner doesn’t own anything, the role owner has no mandate to change the role in whatever way. The role owner is, however, obliged to discuss role content changes with all relevant stakeholders. And that’s all too logical: suppose the finance manager wants to add an HR entitlement to the AR role. That’s not just a decision for the finance manager to make; the HR manager or the HR data owner should have a say in the request to add the HR information entitlements to the AR role. The AR role owner is obliged to find out what other obligations are there, and which other stakeholders must approve the request.
So here we have an owner without any mandate but with many obligations.
And then what struck me was the similarity with Data Governance. In data governance a specific ‘role’ was created to show the difference in tasks, responsibilities and accountabilities, between mandates and duties. It’s the data steward, a person responsible for maintaining data integrity on behalf of multiple stakeholders. This figure has no mandate to manage the data, no ‘CRUD’-like authorizations, just guarding the well-being of the data. Nice term, a steward.
In my opinion we should change the term role owner to role steward. Stewardship is a better fit than ownership. So… let’s appoint role stewards for maintaining the role contents. Don’t use the term role owner anymore; it’s an empty word.
André Koot
IAM Strategist, co-founder of SonicBee
Member BoK committee IDPro
About the Author
André Koot is principal IAM consultant at Dutch IAM consultancy and managed services company SonicBee (an IDPro partner). And member of the Advisory Board of IdNext.eu. He has over 30 years of infosec experience and over 20 years of experience as an IAM expert, acting as architect, auditor and program lead. For the last nine years he has taught a 4-day IAM training course. André contributes to the IDPro BoK as committee member, author, and reviewer.
