I've been working on a declarative security module for WSGI applications I've named repoze.decsec , loosely modeled after the original thoughts about the topic I wrote up a few years ago.

No matter what you might think of Zope, one of the best things that it has had since "day one" is a way to declaratively protect resources in web applications. Zope respects a combination of decorators within code and assertions made through through the web interface (or programmatically) to allow folks to make statements about which portions of their web applications require what level of access to invoke. This access is very granular: essentially you protect a method or an object with a permission, then users can decide which "roles" have some number of permissions in some context. When a user makes a request to the web application, the operation is either allowed or denied depending on the permission that protects the resource he's attempting to access compared to his roles in the context of the resource.

In 1999, this was heady stuff. I had come from a Perl background, where I was writing all of my security checking code in an "imperative" way. Each one of my functions would do a security check and its own login redirection, etc. It was a tragedy. I started using Zope mainly for this feature.

But for some Python web frameworks, good declarative security is still not a built-in feature. They either provide no way make declarative security assertions, or their declarative security model is weak (e.g. in some web frameworks you can only say via code that some method "requires authentication" or is "anonymous allowed", as opposed to being able to make more granular assertions).

Decsec is a mini-framework which users of WSGI-compatible web frameworks can use to implement granular declarative security checking. Its main features are:

• Pluggable mechanisms (via dotted-name callables mostly) for:
  • determining the "remote user" for the current request (using a key in the WSGI environment). This is a value which must be provided by an upstream component.
  • determining the "principals" related to a request. A principal is a username, groupname, or rolename. The remote user can be represented by "n" principals.
  • determining the "required permission" related to a request. A permission is typically a string like "Read", "Write", or "Create". Each WSGI request is assumed to be resolveable to one of these permissions.
  • determining an ACL related to a request. An ACL (access control list) is an ordered list of ACEs (access control entries). Each ACE is a triple of action (allow or deny), principal (a principal name), and permission (a permission name).
• Middleware which:
  • calls the plugin points to find the principals, ACL and required permission for a given WSGI request.
  • checks the ACL using the principals and required permission implied by the request. If the ACL allows, the request is permitted to proceed to the "right hand" WSGI application. If the ACL denies, decsec raises an exception which is meant to be caught upstream by authentication middleware (e.g. Authkit) and turned into an authentication challenge (or at least a notification of failure).

Decsec does not provide any UI, nor does it handle authentication (that's presumed to be the job of an upstream component). It also relies on the policy of its plugpoints to determine how to retrieve and manufacture permission names and principal names. As a result, it's quite general. It's functional and tested, but not documented. I may not do much more work on it until I need to write code in a framework that doesn't have a good declarative security model.