Overall architecture: Authentication/Authorization?

[Felix Schwarz]

Hi,

one point I dislike in the current structure is the missing separation of
authentication and authorization. IMHO this should be clearly splitted into
two libraries so that the Pylons-specific authorization part can be used
independently from the the authentication part.

Ideally, there would be several authorization frontends (e.g. for TG1,
Pylons, ...) but only one authentication core.

Is there any reason which I don't see currently why the current "munging"
makes sense?

--
Felix Schwarz
Dipl.-Informatiker

Gubener Str. 38
10243 Berlin
Germany

www.schwarz.eu - software development and consulting

[Chris McDonough]

FTR figuring out these separation points is in a large part the goal of
repoze.pam (another authentication middleware project):

http://svn.repoze.org/repoze.pam/trunk/README.txt

I suggested to Chris at one point that it might make sense to try to merge the
two projects, as repoze.pam is mostly concerned about "depth" (specifying
interfaces for identificication/authentication/challenge and allowing people to
plug in new implementations for each piece), while Authority seems a little more
concerned about "breadth" (providing a wide variety of plugins). But I don't
want to cramp anybody's style either. ;-)

I think repoze.pam has a fairly sane identification/authentication/challenge
separation story right now. You can see what each type of plugin needs to
implement in the interfaces file at
http://svn.repoze.org/repoze.pam/trunk/repoze/pam/interfaces.py (IChallenger,
IAuthenticator, IIdentifier).

- C

[Kevin Horn]

Could you elaborate on why you think things are munged?

I thought that there was a fairly clear separation between the checker (authentication), and the provider (authorization).  Or am I not understanding your point?

Kevin Horn

[Kevin Horn]

On Wed, Mar 12, 2008 at 4:35 PM, Chris McDonough <chr...@plope.com> wrote:

FTR figuring out these separation points is in a large part the goal of
repoze.pam (another authentication middleware project):

http://svn.repoze.org/repoze.pam/trunk/README.txt

I suggested to Chris at one point that it might make sense to try to merge the
two projects, as repoze.pam is mostly concerned about "depth" (specifying
interfaces for identificication/authentication/challenge and allowing people to
plug in new implementations for each piece), while Authority seems a little more
concerned about "breadth" (providing a wide variety of plugins).  But I don't
want to cramp anybody's style either. ;-)

I think repoze.pam has a fairly sane identification/authentication/challenge
separation story right now.  You can see what each type of plugin needs to
implement in the interfaces file at
http://svn.repoze.org/repoze.pam/trunk/repoze/pam/interfaces.py (IChallenger,
IAuthenticator, IIdentifier).

- C

As far as "breadth" and "depth", Authority really needs to provide both, IMO.  Since the inspiration for it was to provide a replacement for TurboGears 1 "identity", I'm trying to adhere to the TG philosophy of "be flexible, but set good defaults".

I'd like to provide enough components that most use cases that have come up on the TG mailing list can be easily provided through simple configuration, but have clear enough separation that it's relatively easy to write your own methods, checkers, and providers.

Alas, I haven't really had time to study repoze.pam in depth, just a few quick glimpses.  So far it seems to me that we've separated things along roughly the same lines, though obviously repoze.pam is much more formal about interfaces (I was trying to avoid as many dependencies as possible, though I'm still on the fence regarding zope.interface).  I'll get to it eventually though, it looks really well thought out.

Kevin Horn

[Chris McDonough]

Kevin Horn wrote:

>
> As far as "breadth" and "depth", Authority really needs to provide both,
> IMO. Since the inspiration for it was to provide a replacement for
> TurboGears 1 "identity", I'm trying to adhere to the TG philosophy of "be
> flexible, but set good defaults".

Sure.

>
> I'd like to provide enough components that most use cases that have come up
> on the TG mailing list can be easily provided through simple configuration,
> but have clear enough separation that it's relatively easy to write your own
> methods, checkers, and providers.
>

Here's what I've got so far:

- the framework, which accepts a request and calls plugins during
WSGI ingress and egress. It does identification, authentication,
and challenge. It does not compute groups or roles or user
properties.

- The following plugins:

- SQL authentication

- htpasswd authentication

- "insecure" cookie identification.

- "auth_tkt" cookie identification.

- HTTP basic authentication identification.

- form identification

> Alas, I haven't really had time to study repoze.pam in depth, just a few
> quick glimpses. So far it seems to me that we've separated things along
> roughly the same lines, though obviously repoze.pam is much more formal
> about interfaces (I was trying to avoid as many dependencies as possible,
> though I'm still on the fence regarding zope.interface). I'll get to it
> eventually though, it looks really well thought out.

Thanks. The use of zope.interface is really an optimization: its a common
mechanism for allowing us to determine when people have made common mistakes
when implementing one or more plugin interfaces at startup time (we just barf
then) for allowing us a way to describe those interfaces declaratively. People
writing plugins don't need to know anything about it; it's an internal detail of
the framework.

See you at Pycon! (well, those who are going anyway ;-) )

- C

[Felix Schwarz]

Kevin Horn wrote:
> Could you elaborate on why you think things are munged?
>
> I thought that there was a fairly clear separation between the checker
> (authentication), and the provider (authorization). Or am I not
> understanding your point?

IMHO the separation is very good on the Python module-level while it is
non-existent when it comes to packaging. Currently there is only one
"library"/egg while I think that the whole thing should be splitted into
two separate parts so that a user is able to install just the
authentication part without the need to satisfy the requirements for the
authorization modules (e.g. Pylons).

[Kevin Horn]

Well, I was hoping to find a way to get rid of the Pylons dependency, but I haven't thought of a good way to do that yet.  Or at least not a way that I'm happy with.

Splitting into two packages could be done I suppose, though I would prefer not to.  IMO, having to install the extra authorization stuff isn't a big deal (assuming of course that we can get rid of the pylons dependency).

As far as my priorities, I'm really more interested in getting things working properly on TG/Pylons first, and then generalizing to all WSGI situations.  Yes, it sounds backwards to me too :)

Kevin Horn