People should not be Confused with their Personas

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.

(E. Erwitt)

Confusing Mimicry: People Impersonating Personas (E. Erwitt)

What is at stake is best understood by looking at the modeling of users’ access, collective agents, and interoperability.

Users’ Access

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.
Security: actors vs actual and symbolic counterparts

Security: actors vs actual and symbolic counterparts

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.

Collective Agents

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.

Parties and actors are set along orthogonal perspectives, identities for the former, role for the latter.

Parties and actors are set along orthogonal perspectives, identities for the former, roles for the latter.

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).
Powertypes (2) are introduced to manage categories of roles, operations, and objects.

Powertypes (2) are introduced to manage categories of roles, operations, and objects.

That will not be possible without modeling separately entities identified by organizations (collectively or individually) and their personas while interacting with systems.

Interoperability

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.
vvvvv

Actors can be used to characterize communication mechanism between actual agents and 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.

Postscript

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).

Further Reading

External Links

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: