ARPA2 Common Libraries
2.6.1
|
Authentication mechanisms output a visitor's Remote Identity, which is a user identity defined under a domain. Actors can be added to a Remote Identity to map it onto a local userid, as defined by a service domain. Actor Identities may depend on the scene being played, that is, Access Control can grant the privilege when acting like a local identity as provided during Access Control.
Acting and scenes are mere metaphors, but they are a reasonable fit to the technical facility of pulling a Remote Identity into a domain and treating it like an internal Identity. This has several uses:
The general idea is that Access Control delivers an Actor when it grants permission. An empty form of Actor Identity is defined to say this is not really an Actor so that it can be recognised in handling routines, which may then publish the Remote Identity instead. When an Actor is defined, then the challenge to a service is to conceal the Remote Identity from anyone but the administrator, and substitute the Actor Identity in its place. For example, email would alter addresses in headers and envelope and many other protocols would do the same. Web-based documents would be listed for the Actor Identity if available, not for the Remote Identity.
When we say "Actor" we actually mean "Actor Identity".
Whether the translation from Remote Identity can be unidirectional depends on whether it is a Push or Pull Service.
When we say "Push Service" we usually mean "Push-and-Pull Service", with an exception when we explicitly speak of a "Push-Only Service".
On the stage, there are two kinds of Actor, namely those cast to a named role, and those who play an unidentified role in the background. In terms of the ARPA2 Identity model, a similar distinction is made.
<scene>+<actor>@<domain>
where the <domain>
matches the domain that sets the scene (runs the service) and the <scene>
is a userid (not a servicename) with possible aliases. The single <actor>
word cannot contain +
or @
symbols. Note that the use of +
in the <scene>
is formally approved, but likely to cause confusion.<scene>+<signature>+@<domain>
where the +
before the @
is telling for this construct. Access Control may come up with a model for the <signature>
bit, notably including the signature flags and perhaps an expiration day, but it usually defers the creation of the cryptographic part to the caller. The signature flags should include remote domain and remote localpart, so it can derive a consistent Dynamic Actor Identity, which suffices for their use with Pull Services. When the mapping from Actor to Remote Identity is additionally stored, then it will also be possible to use Push Services to contact this identity.An example of this distinction is clear for group handling. Subscribed members would be allocated a member name, and their identity would be of the <group>+<member>@<domain>
form. Guest posting is possible through Dynamic Actors. Whether the reverse mapping is stored determines whether a Pull Service can send responses to the guest; without this stored information, the guest may still be granted access to any group resources, but only through Pull Services.
The data structure a2act_t
represents Actors, much like a2id_t
represents a normal ARPA2 Identity. There are a few differences to note:
txt
part is an empty string. This can be tested quickly, and allows API functions to skip this potentially added information and fall back on the Remote Identity. This special form is called an empty Actor.<scene>
in the userid part, even when this includes +
symbols; this would not be possible with an Identity, where it would always end up in the aliases part. Be careful when mixing Actors and Identities because they are parsed differently; this is not in the txt
part but in the ofs
array. API calls are also clear on this distinction. The <actor>
is stored in the aliases part, prefixed with the last +
sign (which is required). The <domain>
is where it always is, prefixed with the @
sign, which is also required.<scene>
in the userid part, and the same remarks apply as for Static Actors. There are no aliases. The <signature>
is parsed as any Signature would be, and the <domain>
is where it always is. Signatures may initially be just a recipe, listing flags and possibly an expiration value before going through a signature computation.The idea of an ARPA2 Group is bold, but incredibly useful: every member of a group is given an address within the group, and it looks like <group>+<member>@<domain>
so that routing always passes through the <domain>
that defines the <group>
, and so that the <member>
name is local to the group. Actual communication needs to translate from/to an actual delivery address for the addressed <member>
names. Clever forms of syntax have been devised to address one, multiple or all-but certain <member>
names.
Upon arrival of communication for a group, the sender becomes an Actor, and by doing this starts to look like its member name. When passing out traffic to a group, the addressed group members translate to a delivery address, often including the one that the sender originally used.
The <group>
is an example of a <scene>
. The customary use of a <member>
is for subscribing members but, if supported, visitors may obtain a dynamic name and continue. Whether this is permitted is up to Access Control for the <group>@<domain>
.
NAT is terrible. It disables peer-to-peer freedom, and as long as we consider IPv4 worth supporting it means that we need to use intermediate servers for all we do. And that is not always in the interest of privacy (and if you don't care about yours, you may be dragging down others with your carelessness). Clearly, for the Internet Protocol the addition of NAT blocks progress.
The problems with NAT are mostly due to limited port spaces, and the lack of clarity about bidirectional translation, and support for end-to-end connections. For the much larger address space of Actors, this need not be a problem. The Static Actor may be considered equivalent to port forwarding, which works well in every situation. The Dynamic Actor may use a timeout if this is desired for policy reasons, such as storage restrictions for Push Services.
So on the whole, the problems with NAT for IPv4 do not seem to reproduce when we translate ARPA2 Identities to Actors.
A few support functions are defined to work with a2act_t
structures:
The parser function works along the lines of a2id_parse()
, and the others test if the Actor is empty, static, dynamic or recipe-for-dynamic. Rules are likely to hold recipes for dynamic addresses, which must then be passed through a2id_sign()
to complete them to the dynamic form.
The most interesting places where an Actor structure pops up is when a Remote Identity is passed into an Access Control function:
This tries to communicate from remote
to local
, using whatever protocol, and if out_level
is set to access_comm_whitelist
then the value in out_actor
should be interesting to use.
For Document Access, the pattern is almost the same:
In both patterns, most upcoming functions calls would mention remote
and &out_actor
together.
It is often useful to allow a user to "downgrade" their login_identity to a more specific acl_identity in a separate operation. This may be useful to select a role or group membership, to preselect an alias, and so on. This may be done in response to such things as an authorisation identity presented during login, a web-interaction where a user selects one of multiple roles, or perhaps during the flow of a protocol. A good example of the latter would be SMTP, where the MAIL FROM: command selects a more specific identity and the From: header may be even more specific.
This question comes down to "may I act on behalf of" and makes a comparison, including Rules DB access if needed, between a authentication identity (the login_id) and a desired specific authorisation identity (the acl_id). When successful, the system can continue to treat the acl_id as if it were the login_id. This function can fail, in which case the surrounding operation should also fail due to lacking Access Control privileges to perform the requested operation. The test for this is:
Note that the previous functions had an output argument &out_actor
, and although &acl_id
could be considered taking on an Actor Identity, it works as an input argument in this call.
The access_actor() call succeeds trivially when the two arguments are the same and represent an existing user. The call may be made more than once in succession, gradually reducing the access privilages and/or allowing to trivially skip an optional reduction in access privileges as it may occur in a protocol or service program. Every step allows the use of acl_id
as a replacement of the login_id
, also for use with other Access Control functions such as access_comm()
or access_document()
.