Let's say you own a domain name, and have software
that uses ARPA2 Access Control. How, then, can you
grant or revoke access?
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.
identitylibrary 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
identitylibrary 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).
accesslibrary can be asked if Communication Access from a remote
email@example.com our own
firstname.lastname@example.org 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
accesslibrary how these results are put into effect.
- The same
accesslibrary handles Document Access, where a local or remote
email@example.com to read write or otherwise work on a document. The
accesslibrary presents a series of flags that indicate the rights that apply.
grouplibrary 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.
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.
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.
To manually update Communication Access in the Rules DB, the admin can post commands like
a2rule comm add \ local firstname.lastname@example.org \ remote email@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 firstname.lastname@example.org \ remote email@example.com
The output is (currently) the contained Rule, which reads
You might be surprised how little information this produces, but this is the actual stored data. The
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.
%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 firstname.lastname@example.org \ remote email@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 firstname.lastname@example.org \ remote email@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.
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 firstname.lastname@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.
This is actually not implemented yet in ARPA2 Common v2.2.6, but the pattern will be similar. Thelocal
email@example.com 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.
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 firstname.lastname@example.org \ identity email@example.com \ marks RW
This already shows the magic of ARPA2 Groups; although
firstname.lastname@example.org signs up for the
email@example.com group, he does so under a member alias
vegan. Within the group, he will therefore be known as
How well this abstraction works depends on the software and protocol; for example, an email mentioning John's underlying identity
firstname.lastname@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
To track down abusers, there is also commandline support for looking up the identity for a member,
a2rule group get \ member email@example.com
This would list the Rule in the database,
#a2xs %RW ^vegan@firstname.lastname@example.org
#a2xs marks this as the work of the
%RW marks read/write privileges to group resources, and
^vegan@email@example.com is a trigger that indicates the member alias
vegan as bound to an underlying identity
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.
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.
There is proper documentation for ARPA2 Common, which should guide you through the ideas, the API design and set you up for programming your first ARPA2 Common integration.
- Read the Overview to get an idea of the scope of ARPA2 Common.
- Identity and Selectors work out our may ideas about identity and integrate with Realm Crossover technologies that allow you to Bring Your Own IDentity.
- Access Control for Communication and Access Control for Documents are two examples of the abstract idea of Policy Rules.
- ARPA2 Groups can iterate over members to find recipients, after using Actor Identities to protect the sender. Actors are a by-product of Access Control, and are given when group resources are being accessed.
Many of these ideas are new, and may need to trickle in. Rest assured that they are part of a highly potent amount of control over your online identity, which we set out to protect. Also rest assured that we worked really hard to support integration with all sorts of software and protocols.Go Top