ARPA2 identity handling Python/WSGI middleware
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
README.MD
WSGISASL.MD
wsgisasl.py

README.MD

README for ARPA2 WSGI middleware

WSGI enables middleware, which is a perfect place for enforcing ARPA2 Identities, ranging from authentication to authorisation through access control.

Background links:

HTTP SASL handled with WSGI SASL

Most protocols that require authentication make use of the SASL protocol. Maybe it is better to say that SASL is a kind of tunnel that passes through a protocol to exchange authentication in a flexible manner. Most importantly, the mechanisms can be plugged into software independent of the protocol that uses SASL and one infrastructure can be shared by all the protocols.

HTTP has not had SASL implemented. We have specified HTTP SASL to fix that, and stop the ongoing need for authentication systems built into the (rather insecure) JavaScript namespace. We are implementing it with a few Java demonstrations, as well as a browser extension with native messaging so we may reuse desktop credentials from a trusted application outside the browser. Yes, that includes one's Kerberos login and yes, it enables the use of pseudonyms during realm crossover.

We are hoping to develop a Python WSGI component for the server side. It would sit between the web server and WSGI application, and detect 401 or 407 responses, annotate them with SASL authentication option and hope to find a browser that responds to the option of SASL authentication.

Current status: There is no reasonable support for server-side SASL at this moment. We have asked others to help out with this.

Bring Your Own IDentity

We are considering a BYOID mechanism based on Diameter servers hosted under domain names. This is not a web-only technology, so we are not limited to HTTP and can make a choice for a more dedicated technology.

Diameter is the sequel to RADIUS; its security is better so it can be used for such realm crossover purposes; indeed, there are SRV records in DNS for this kind of purpose. Diameter's support for bulk interactions and routing of requests and responses has also improved. Finally, it is easier to extend with notions such as SASL fields.

With this in mind, a server receiving a client identity john@example.com can lookup the Diameter server for example.com and relay SASL traffic to the realm. It does not need any local credentials to allow for this to work; all it needs to do is use TLS for trust in the link to the backend Diameter server.

This is not the only way in which we think BYOID can be achieved. It will me much more powerful once we get our projects for Kerberos going: Impromptu Realm Crossover (KXOVER) and TLS-KDH. The advantage of these mechanisms is that a crossover relation is made between realms, not just for individual queries of individual users. This makes it extremely efficient for bulk use, but it will also take longer to get established. It is useful though; TLS-KDH authenticates thousands of times faster than tradition public-key certificates, and it resists quantum computers; KXOVER currently cannot match that last point, but will develop in that direction too. SASL is the short-term solution that can integrate seemlessly with this same approach.

ARPA2 Access Control

The ACL setup that we envision is flexible, generic and fast. More importantly, it is suitable for realm crossover uses.

We are building libraries to support the general evaluation of this model, along with change subscription to keep dependents informed.