Pyramid Authentication/Authorization Questions

[Jonathan Vanasco]

I have 2 large Pyramid applications that use an in-house authentication/authorization and request pre-processing system.  I'm in the middle of porting a legacy mod_perl app to Pyramid, and weighing the options of: (i) converting everything to more native Pyramid code, or (ii) abstracting the current system into something more extensible. 

One of two existing apps were originally built on Pylons, the other dates back to either before Pyramid's current auth existed, or at least was as robust as it is now.

Both apps use the Pylons style "handler" approach to writing view callables.  A base handler class exists with some core pre-processing logic:

* initialize some request vars

* handle any cookie processing (autologin cookie, preview access, etc)

* handle API vs Web request differences; setup context

* require HTTPS or specific TLS versions

The base handlers are then subclassed into Authorization policies, topline options like : LoggedIn/ LoggedOut/ LoggedAny (e.g. pyramid.authorization.Everyone).  The "LoggedIn" are further subclassed into discrete permissions, and eventually we have a  `/views` directory with subclasses, and their methods are hooked into Pyramid via `@view_config` decorators.

This has worked well for 10+ years and the applications have scaled very well performance-wise, but the maintenance on them leaves a bit to be desired as we need to upgrade/patch each application separately for most auth related issues and improvements.  

I'm wondering if there are any components in Pyramid2 that may be used to develop a simpler-to-manage replacement for existing apps and give a good blueprint for the future.

I think a bunch of the pre-processing could be handled on Tweens (much of this is invoking or manipulating request properties configured via `add_request_method`).  

The big disconnect I keep having with Pyramid's Auth(s) system(s) are:

* requiring an unauthenticated user.  

* applying different styles of required authorizations

Our authz tend to be more complex than the standard Pyramid examples and any open source Pyramid app I've seen.  I think the easiest way to describe it would be like Facebook's group policies:

* user type - normal, group administrator, group owner, app employee

* group administrator permissions (computed or database stored based on user+group combination)

* user or group qualities (some things require a specific TOS version optin, others require a photo to have been uploaded)

Beyond that, we are also able to use the subclasses to set the failure policies - e.g. where the redirects are routed to - as these are logically grouped by the handlers. 

The app I am currently porting does not have all these constraints, and is much simpler, but this seems like the perfect time to rethink and potentially redeploy some legacy code.

Has anyone worked on something similar and can share tips, or seen any potentially similar open source projects we can look to for inspiration?