Re: [cgiapp] Re: user authentication / rights management

[Michael Graham <suppressed>]

Mark Stosberg <suppressed> wrote:

> On 2006-02-16, Michael Graham <suppressed> wrote:
...
> >     <Location /admin-area>
> >         auth_protected = 1
> >         auth_groups    = admin
> >     </Location>
>
> I used to design my authorization like that, but I don't recommend it
> anymore. I explain more about why in this blog post:
>
> http://www.summersault.com/community/weblog/2006/02/04/access-in-urls-considered-harmful.html

Hmmm... you make a good argument in that post.  I think I've grown
accustomed to URL-based schemes mainly through the legacy of HTTP Basic
Auth (e.g. .htaccess files).  You make a good case for why the web is
outgrowing that model.

But having a private /admin area does give me the security to know
that a whole great big part of my application is completely shut off to
most of the world. 

After reading your article, I know I probably *shouldn't* think this
way, but I find that when I try to imagine managing a large
multi-module site without this kind of coarse-grained access
control, my head starts swimming.

Mind you, since CAP::Config::Context can also do context matching based
on Application (i.e. the Module of the currently running webapp), I can
probably still do this but avoid hiding behind access-based URLs:

    <App MyBlog::Admin>
        auth_protected = 1
        auth_groups    = admin
    </App>

But of course this doesn't address your main point:  often two users
with different privileges will run the same application.  For this,
you'd want runmode matching as well, something like this:

    <App MyBlog::Comment>
        auth_protected = 0
    </App>

    <App MyBlog::Comment/post>
        auth_protected = 1
        auth_groups    = user
    </App>

    <App MyBlog::Comment/delete>
        auth_protected = 1
        auth_groups    = admin
    </App>

But (alas) CAP::Config::Context doesn't do runmode matching (yet). I
had originally wanted to add this feature, but I ended up leaving it
out at the last minute, because real world apps often set the run mode
*after* they load the config file.

But now that the new C::A::Dispatch sets the run mode before the app
even starts, this feature starts to become feasible again.  I'll look
into adding it when I get some time to experiment with the new Dispatch
module.

Side note:  it's important to note that in this discussion, we're only
addressing controller-oriented security.  Data-oriented security (i.e.
which particular users have access to which particular blog posts) is
something else entirely (IMO).


> I sent Cees a patch to the Authorization plugin which adds several
> methods to help with group-based authorization.
>
> With those, I can easily declare:
>
> "All the run modes accessed through this module are accessible only to
> these groups".
>
> And they I can override those general rules with exceptions for specific
> run modes.

Sounds interesting!

> It's easy to use, and the conversion process actually brought out a
> weakness in the old scheme. With access in URLs, it was easy
> psychologically to think "Oh, I'm in /user, everything accessible from
> under here must suitable users". The reality was that because of shared
> modules, sometimes too much could be exported.

This is a good point - the obvious danger is with runmodes that are in
a common base class.  

> I'd tricked myself into believing that the design was easier to secure
> and test. The reality I found was both authorization schemes needed
> careful review and testing.

Yeah - definitely true!


Michael


---
Michael Graham <suppressed>


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed