Programming Projects

You asked for it! (Ok, maybe you didn't)

Tuesday, September 9, 2003

Security Semantics & Protocol Layers: Church & State v0.1

The question on the table (to be a bit pretentious) is "Why should I put security features in the api when they are already implemented in the transport layer?" (the fact that we're talking about wiki apis and the transport in question is http is actually quite irrelevant.)

There's something I want to clarify before I start on this:

API design is Protocol design.

You can disagree with that statement if you like. I support your right to be wrong.

When you are defining an interface, you are defining the semantics with which that interface will be accessed. You are ALSO dictating, to a nontrivial degree, the operational structure of the program that's going to use that interface. (I don't know if I'm being clear here but I do mean two sublty distinct things. It's not important enough to dwell on yet.)

You are defining the semantics for interoperability between multiple components of ware (being hard or soft.)

To break apart these semantics and place them in different architectural levels (in this case between Transport and Application) you place significant constraints on portability and flexibility for future implementations and their growth.

Future ports of the protocol/api will require some kind of substrate that satisfies the security concerns completely. AND future expansion of the API will require that this is handled entirely outside of it's scope.

More specifically...

The things that don't satisfy me about this approach are:

binary security. You have no control over granularity (who can get to what. Who can view? Who can edit?) and you're stuck with making major architectural modifications to the spec down the road. These things WILL be concerns if this is to be implemented in any serious way.
no possibility of multiplexing connections. (If you use http authentication you're pretty much stuck with architecture and policy decisions of networks and who implements them and THEIR security concerns rather than being able to define that for yourself.)
aesthetically it's really just not very clean.
If you do implement in something other than xmlrpc over http then you have to research whether or not your substrate can provide you with the precise same security features that http does. You are, in essence, giving away feature design.

So what DO I want out of the interface I go with (that's germane to this discussion)?

massive multiplatform interoperability. I want to be able to implement this in COBOL and LISP on an old wang VS machine or straight in emacs. An API means that it doesn't have to exist only across a network. A staticly linked library exposes an api just as surely as anything else does.
complete control over security concerns. I want to have multi-repository support (within the same url) and I want some people to have access to read-only versions, some people to be able to create repositories, and some people to be able to edit (as well as "append only", which is a really great idea a friend of mine had. But I'm sure he'll chime in soon enough.) I want login/logout, timeouts, concurrency control (person A can only have N connections running.) And I want access to all auditing data.

It sounds like overkill I'm sure. But with the addition of 2 methods and an additional parameter to each other method, the hooks for security policies of arbitrary complexity can be accommodated.

Besides if you don't want to bother with security you can always void out the implementations.

It's distinctly possible that the concerns I have are simply too tight for most people out there and for most casual implementations of a wiki api.

2:11:24 AM

comment []