Access 3: ARPA2 Access Control and Groups for Admins

// under identity access hosting

Let's say you own a domain name, and have software that uses ARPA2 Access Control. How, then, can you grant or revoke access?

This article is part of a series on access control and is related to another series on identity.

Our software library ARPA2 Common does general tasks for all our projects, and it is designed to easily integrate into the protocols and software made by others.

First, let's briefly explain what our libraries do; then we turn to the way an admin would manage these rights.

The identity library makes it easy to work with ARPA2 Identity, including its pattern form ARPA2 Selector. It involves parsers that dissect a string into its components, it can iterate over its parts, compare if one is more special than another, and so on.
A special feature if the identity library is that it can make identities valid only in a specific context. For example, an email address could be setup to only accept email from a particular sender (or sender domain).
The access library can be asked if Communication Access from a remote ruser@rdomain.com to our own user@domain.org is granted. The answer will be that it is on the white, black or grey list -- or perhaps that it should be subjected to a honeypot! It is up to the software calling the access library how these results are put into effect.
The same access library handles Document Access, where a local or remote user@domain.com wants to read write or otherwise work on a document. The access library presents a series of flags that indicate the rights that apply.
The group library can be used to iterate group members. Again, this is a generic mechanism that is not specific for, say, email. Some fancy tricks are possible to address one or more specific members, or perhaps all but a few, in a way that conceals their actual address to anyone but an admin looking for an abusive group member.

Rules Database

ARPA2 Common uses an efficient memory-mapped database that we call the Rules DB. It takes great care to do this efficiently. The database is normally stored in the /var/lib/arpa2/rules/ directory, but an environment variable ARPA2_RULES_DIR can be set to override that.

The libraries mentioned above use this database. They usually need to do only a few lookups, so they are extremely fast. On top of that, the Rules DB is built on LMDB which is extremely fast.

The a2rule utility is used to manually write into the database. A second utility that automatically extracts configuration data from LDAP is being developed. The design of the database allows future exchange of data from an identity hoster to a service hoster, with protection against iteration of the database by any party.

Communication Access

To manually update Communication Access in the Rules DB, the admin can post commands like

a2rule comm add \
   local  john@example.org \
   remote mary@example.com \
   list   white

This white lists, so grants access, from Mary to John. This setting is agnostic of protocols or software, so it would apply to any email, chat, voice or other forms of communication that you might think of. As long as it uses ARPA2 Common to look into the database.

Pass in too little, and you will receive feedback about the command syntax. The general form is an action on a class of objects, with additional parameters after a keyword name. The order of the <keyword> <value> pairs is arbitrary.

a2rule <class> <action> [<keyword> <value>]...

The contents of the database can subsequently be queried with

a2rule comm get \
   local  john@example.org \
   remote mary@example.com

The output is (currently) the contained Rule, which reads

#a2xs %W

You might be surprised how little information this produces, but this is the actual stored data. The local and remote values are hashed into the database key, but not stored in it. This means that the database can be an oracle for questions, but it cannot be brutally iterated for communication data.

The part %W flags the entry as white-listed. The part #a2xs does not even mean anything, it is merely a (comment) marker for the a2rule tool. This helps to keep the tools from interfering with each other's data.

What you can get, you can also delete,

a2rule comm del \
   local  john@example.org \
   remote mary@example.com

You cannot add what is already there, and you cannot delete what is not there. This can raise errors. To remedy that, there is a variation that assures that the new content is set to a desired value,

a2rule comm set \
   local  john@example.org \
   remote mary@example.com \
   list   white

This works like add after an optional del. A good use is to assure that Communication Access maps to a certain list.

The remote is an ARPA2 Selector, and a full ARPA2 Identity is just one possible form it may take. On the other end is the most general form @. which covers everything. Since Communication Access looks for the most concrete match to the Remote Identity, it is possible to set a default treatment with something like

a2rule comm set \
   local  john@example.org \
   remote @. \
   list grey

You have now enabled grey listing for all undefined Remote Identities. Grey listing defaults to refusal of communication, but it may pose a challenge to the remote. When the challenge is satisfied, a white list entry may be set for that Remote Identity.

Document Access

This is actually not implemented yet in ARPA2 Common v2.2.6, but the pattern will be similar. Thelocal user@domain.name identity would be replaced by a name for a document or directory, and the list selection would be replaced by flags that grant particular kinds of access.

Group Members

A rather different application of the Rules DB is group membership. The underlying engine is the same however, and so the a2rule tool is used for this too.

a2rule group add \
   member   cook+vegan@example.org \
   identity john@example.org \
   marks RW

This already shows the magic of ARPA2 Groups; although john@example.org signs up for the cook@example.org group, he does so under a member alias vegan. Within the group, he will therefore be known as cook+vegan@example.org.

How well this abstraction works depends on the software and protocol; for example, an email mentioning John's underlying identity john@example.org would still leak that information, but email headers might be rewritten by a privacy-aware piece of software.

The mapping from the member alias to the underlying identity is still used for delivery, of course. To that end, software iterates over the group with the ARPA2 Common group library.

To track down abusers, there is also commandline support for looking up the identity for a member,

a2rule group get \
   member cook+vegan@example.org

This would list the Rule in the database,

#a2xs %RW ^vegan@john@example.org

The comment #a2xs marks this as the work of the a2rule tool, %RW marks read/write privileges to group resources, and ^vegan@john@example.org is a trigger that indicates the member alias vegan as bound to an underlying identity john@example.org.

As before, there are also a2rule group del and a2rule group set commands with similar meaning. In the end, a2rule manages Rule Sets, and so set operations are used for individual Rules.

Demonstration Code

An early bit of code to demonstrate the ideas of ARPA2 Common is AxeSMTP. This performs a few tasks:

Destination addresses are subjected to Communication Access. This not only involves the recipient address but also the sender.
Destination addresses with signatures are compared against their context. The address might have expired, or be a misfit with the communication context, in which case it is rejected.
Rules in Communication Access may spell out aspects that ought to be checked through a signature. This would be where unsigned destination addresses fail, or ones with too little constraints built in.
Actor Identities are applied when they are encountered during Communication Access.
Group Member Iteration is performed for group identities. (The current Group Iterator fails on non-group identities; in Postfix, you can remedy that with a transport for group identities.)
Source addresses with an incomplete signature (flags and optional expiration, but no actual signature) are signed on the way out. Do not apply this to group mail.

This can already do more than the few simple examples given above. Please interact with a2rule to see syntax suggestions, and do read the manual page.

Rick van Rein