Confronted with the ubiquity of IT systems and the blurring of traditional fences, enterprises grapple with the management of accesses and authorizations. Hence the importance of a clear distinction between agents, organizational units, and systems users.
What is at stake is best understood by looking at the modeling of users’ access, collective agents, and interoperability.
Roles (or actors in UML parlance) are meant to provide a twofold description of system users in order to combine two perspectives: organization and business process on one hand, system and applications on the other hand.
That can only be achieved by maintaining a clear distinction between actual agents, able to physically interact with systems, and roles, which are symbolic positions defined by and relative to organizations. Since mapping people and organization with systems users is the primary purpose of access rights management, lumping both sides under a single concept would definitely preclude the modeling of typical access scripts:
- Anonymous: no authentication or authorization.
- Registered user (role): user name and password are matched to user record.
- Identified person: authentication of external identity.
- Registered person: identification of a user with established external identity.
Given that authentication and authorization procedures depend on matching actual agents with their system symbolic representations (authentication) and roles (authorization), ignoring those distinctions would sap the whole security architecture.
Confusing agents and roles may also prevent a proper management of collective authorizations.
At enterprise level parties can be identified physically as individuals or nominally as groups. But from a system perspective interactions can only be carried out by actors with physical identities, whatever their nature, users, systems, or devices.
Managing accesses therefore requires an additional level of complexity, namely the relationship between collective and individual rights:
- Parties can be intrinsically individual, collective, or contingent on circumstances (a).
- As far as collective entities are concerned, access rights can directly allocated on behalf of group membership or delegated to named individuals (b).
- Rights may depend on their origin and compatibility (c).
- Roles allocation may be conditioned by both entitlements and specific rights on operations and objects (d).
That will not be possible without modeling separately entities identified by organizations (collectively or individually) and their personas while interacting with systems.
From smartphones to dumb appliances, things are unceasingly moving around networks and swapping places with people. Given the number, diversity, and turnover of interacting parties, systems are in no position to keep tabs on what is happening to agents behind the roles. Interoperability is therefore fully subordinate to the reliability and versatility of actors’ functional capabilities with regard to agents (organization) and applications (systems):
- Agents identified externally are classified with regard to communication capability: users (natural language, digital, analog), systems (digital), and devices (analog).
- Applications are classified with regard to their communication requirements (services, users interfaces, RT interfaces, …).
- Actors are used to map agents to applications.
That formal distinction between agents and actors comes to be critical when access rights are to be checked for peer-to-peer transactions carried out across multiple participants.
Besides its benefits, the validity of this perspective is borne out by its congruence with enterprise architecture layers (business, systems functionalities, platforms technologies) and model driven engineering (e.g computation independent, platform independent, and platform specific models).
- Use Cases
- Use Cases Patterns
- User Patterns
- Functional Connectors
- Caminao & Archimate
- Building Bridges
- Modeling Paradigm