Looking back to the Objects of the corporation, which I defined back in 2010-07-05, I felt the need for some minor adaptations in order to comfortably derive the elementary actions for its manipulation from this model.
Let’s state therefore: the identity has closed a contract with the organization, not necessarily a legally binding agreement; whereas usually it is. Although not in focus of the Identity Management the digital identity’s lifespan within the corporation starts with an agreement. There may be more than one of them like a freelancer contract and a bank account creating a customer-supplier relationship or an employment contract and the membership in the workers council.
To take full advantage of the possibilities to automate role assignment we could later resolve the fine structure of the object organization. For now however it may be sufficient to deal with a monolithic object.
Contracting is usually done according to a standard contract type covering at least one standard position, e.g. sales representative of securities trader. Each of these standard job descriptions covers at least one functional role.
The functional role just specifies functions to be performed. What still is missing is the information object to be accessed. Therefore the business role needs to be localized by further constraints in order to bind it to specific permissions. The result is stored in the business role. There are of course many more business roles than functional roles, accessing different incarnations of the same information object type.
According to the RBAC definition permission is an operation on an (information) object.
Constraints may be specified in the same agreement as the function or in additional agreements and applied to the business role. For example the amount of money, a bank clerk is allowed to sign a credit contract for, may be limited. Or the authority to purchase material may be limited to a specific organizational unit.
 |
| IAM-objects & non-IAM-objects |
Everything starts with an agreement …
We only care about the digital identity in the corporate context if it maintains any kind of relationship with the organization or an organizational unit (OU).Let’s state therefore: the identity has closed a contract with the organization, not necessarily a legally binding agreement; whereas usually it is. Although not in focus of the Identity Management the digital identity’s lifespan within the corporation starts with an agreement. There may be more than one of them like a freelancer contract and a bank account creating a customer-supplier relationship or an employment contract and the membership in the workers council.
To take full advantage of the possibilities to automate role assignment we could later resolve the fine structure of the object organization. For now however it may be sufficient to deal with a monolithic object.
Contracting is usually done according to a standard contract type covering at least one standard position, e.g. sales representative of securities trader. Each of these standard job descriptions covers at least one functional role.
The functional role just specifies functions to be performed. What still is missing is the information object to be accessed. Therefore the business role needs to be localized by further constraints in order to bind it to specific permissions. The result is stored in the business role. There are of course many more business roles than functional roles, accessing different incarnations of the same information object type.
According to the RBAC definition permission is an operation on an (information) object.
… and ends up in an "authorization".
The identity’s access to an information object - expressing the use of the object - is stored in the authorization object. There may be one or more authorization object per identity.Constraints may be specified in the same agreement as the function or in additional agreements and applied to the business role. For example the amount of money, a bank clerk is allowed to sign a credit contract for, may be limited. Or the authority to purchase material may be limited to a specific organizational unit.
No comments:
Post a Comment