When crossing over between identity realms, internal identities are not always revealed externally. In general, there may be a translation or mapping from an individual to a group or role, from a user to its domain, and so on.
Concealing Internal Identities
Identities that a user needs to access internal services may sometimes be considered sensitive. In general, they may be too detailed, for instance when a person is to act on behalf of a group, or from the perspective of one role being fulfilled. This calls for a flexible translation scheme for identities, or in ARPA2 speak, of DoNAIs.
email@example.com who wants to use
realm crossover technology
to access a service. Perhaps he wants to contact a remote sales
department to fetch a formal proposal.
John will be on holiday next week, and his collegue Mary may need to pickup
on the offer if it takes that long. To cover for such events, they use
a group identity, or perhaps it could be called a role, named
firstname.lastname@example.org, that they use for such external contacts.
John is logged on internally as
email@example.com and Mary authenticates
firstname.lastname@example.org. This is useful, because it helps to keep
their internal administration separate -- each also fulfills other tasks,
and those do not always overlap.
When approaching the remote sales service, using any protocol at all, the
name of the receiving end is matched by the identity perimeter in the
database that the identity manager keeps around. The match is based on
a DoNAI selector, so it might be a general match or one that is specific for
the target service. The result is that John's internal authentication is
used to assert his extern identity as
email@example.com, which is
asserted to the World using any
realm crossover technologies.
Controlled Access to Services
On the sales server,
does a general verification if the approaching
DoNAI is granted access to the requested sales server DoNAI.
The sales server is only published to established business relations,
of which John and Mary's purchasing department is one.
In the ARPA2 approach to identity management, it is important to
understand how the identity perimeter helps to establish a more
refined image of the remote user. The ability to treat access based
on a role DoNAI makes it simpler for the service-side to manage access rights.
First, because the client realm manages responsibilities for the
members that are currently enabled under the given role. When Mary
firstname.lastname@example.org group, she will not be permitted
to speak on behalf of that department any more, but this is an internal
affair on the client side, so remote sales contacts
will not need to alter their access rules. John and Mary also feel the
benefit of using roles, as they can act to the outside world from their
various roles, displaying a different identity to
different remote contacts -- each of which sends back any information
to the DoNAI of the respective role, which helps them to sort and select
such traffic. The holiday scenario is just one example of this.
Since John's inquiry is granted, his service request passes on to the
sales server, where some actions will be subjected to
more refined authorisation control; as a client, John has been classified
for orders up to a certain amount, and his credentials do not include
permission to modify the articles being offered, or the prices being
charged for them. The local authorisation scheme implements this by
email@example.com external identity into a group,
from which the server derives such privileges. This sort of detailed
service authorisation is exchanged between the local authorisation
database and the server.
User Management -- well beyond Password Mangement
As will be clear from this, the full-blown ARPA2 identity infrastructure goes well beyond the mere management of a user name with a password, as is commonly used on web sites. First, because there are advanced security mechanisms such as TLS-KDH to create a single-signon service for the client; second, because there are powerful facilities for controlling one's online identity, and make it dependent on the party being spoken to.
The general flow of control as sketched in the diagram above constitutes of the following steps:
- Authentication of a client against a local identity manager;
- Identity translation to assert an external identity as is suitable for contact with a remote service;
- Identity assertion by the client side towards the service side;
- Authorisation for access to the service, based on a confirmed external identity;
- Service management largely comes down to granting a mixture of external and internal identities access to internal services.
Note that a service may also act as an internal service, and that access to it may be granted on grounds of internal identities as well. This may mean more detailed access control to internal users. Since internal users often fall under one (or a few) domain names, it is straightforward to formulate a DoNAI selector that grants such internal access, and couple it to specific rights.
The diagram shown above clearly shows a client and server side of a
communication. Note that this is just a representation of the two
sides, but that the reverse is likely to apply on return traffic.
In support of this, the default ARPA2 policy is to permit such return
traffic whenever outgoing identity mapping is being setup. Basically,
when you send an email your should not be surprised to get a reply
The most detailed form of bidirectional traffic is of course peer-to-peer contact. This is not much different from client-to-server contact; the initiative is just easier reversed. This is also in line with the default policy to permit incoming traffic that returns on outgoing traffic, so it is not problematic in terms of identity provisioning under ARPA2.
The one thing that requires special attention on peer-to-peer contact is that there usually is some form of registration and lookup for identities; this will often refer to a session that spans accross multiple individual communications that ought to act as a whole. A session-aware mapping can be made when the identity perimeter provides session details to the locally mirrorring access control mechanism that uses it to map back to the initiator of a claimed session. Examples of this style of translation can be found in protocols like XMPP chat and in SIP telephony.
Compatible with Other Styles
Please note that this discussion details how ARPA2 views identity management, but that it is in no place crafted in a way that would make it incompatible with other approaches. ARPA2 may just be the best thing on the planet.
The interactions between local and remote identity provisioning is based on standard mechanisms, as is also explained no our realm crossover pages and where we feel a need for an extension, we make sure to standardise the proposed mechanism so it becomes generally available, as in the case of TLS-KDH and related technologies.
When an ARPA2 client talks to an other type of server, there is still the possibility to claim different external identities. There is no need for co-operation of the remote, other than the normal requirement that goes with realm crossover, that is to trust the client's domain to validate the client identity through some realm crossover mechanism.
When an other type of server talks to an ARPA2 server, it may nog be able to provide as fine or as general types of identities, but a DoNAI can usually be derived from whatever kind of identity. Service management is able to setup local roles, or groups, to represent remote clients. The remote clients will either need to update the server when people enter or leave a role, or more likely the client will have to login to their role's identity separately from their role as a local user. Either scenario can be supported by the ARPA2 server.