GSOC Proposal : Improving Rack Auth

[Lakshan]

Hi All,

Inspired by Authkit (http://authkit.org) and Merb Auth I was wondering
how a complete Rack based authentication and authorization framework
would help for Ruby web applications. I have come across many cases
where it is possible to abstract and re-use authentication, rather
than lock it to be application specific. So in my belief project to
improve and extend authentication of Rack could be beneficial to Ruby
community.

Here are the major features I wish to work on for Summer of Code.

1. Implement New Handlers (by extending Rack::Auth::AbstractHandler)

- Form based endpoint

- Cookie based authentication

- Single Sign on with Param (e.g. for API access)

- One custom handler as a sample (i.e. LDAP or Facebook Connect)

2. Support cascading authentication handlers (e.g. Could define to try
cookie first, then form and then param)

3. Build a unified key-value store (probably using moneta) to hold
credentials and roles.

4. Support storing data fields (i.e. password) by encrypting with a
defined encryption method and salt.

5. Implement generic and flexible authorization system

- Application route level authorization

e.g.:

/admin/* - requires admin role for all sub paths (role
based)

HTTPS - controlling scheme to be only used for paid account
users (I have written a similar middleware earlier - http://tinyurl.com/db7jyr)

- pass the roles enabled for a user to application (e.g.
"rack.auth-roles" => ['writer', 'reviewer'])

- Render correct status codes on failure (401 - for
authentication failure, 403 - for authorization failure)

I would like to have your comments and suggestions on this idea.

[Daniel N]

Hi,

As we talked about on email this is happening.  I'm 90% done on an initial cut of a port to rack of merb-auth.  There's some differences due to the conceptual differences but a first rough cut of the Authentication part should be done this week.  I will announce it on this list as a rough cut.

The Authorization part is yet to be done.  For me, authorization should be part of it, but it does not mean roles.  Authorization is just a question about an object, the logic is different between applicaitons. 

To me, for authorization we need a mechanism to execute the logic, an interface to ask the question and some structure to capture and deal with the results.  If people want to implement the logic via permissions and roles then so be it, but this should not be the required logic.

I'll follow up with some code shortly...

Churs
Daniel

[Daniel N]

Hi Lakshan,

I'm really sorry if that came across a bit harsh.  That was not my intention at all, I really suck at email :(

If you're interested in working on this system with me I'd love the help.  The authentication part is conceptually a port of merb-auth, so we'd need to get some strategies in place, but authorization is a blank page. 

I have thoughts on authorziation and what it will look like.  I've done a fair bit of exploring in the past and came up with something that I think will be workable for both simple and complex tasks.  If you'd like to work with me on it I'm more than happy to get cracking with you via GSOC if you think we can, or just on our own time, but I'm eaqually comfortable if you tell me to get lost and just do your own thing ;)

What I'd like to see happen is the mechanism I mentioned before being put into place, and then some generic permission / role system built on top.  I think this would be a great system to have available and one that could be done generically without locking people into roles and permissions only, since people could elect to include roles/permissions or they could just roll their own logic on top of the authorization system.

Choo think?

Cheers
Daniel

[Lakshan]

Hi Daniel,

Oh no.. it wasn't harsh at all! It was me who blindly came up with
this idea without knowing you have put efforts into it. I'm looking
forward to work with you to bring this idea forward (whether it is
selected to GSOC or not). My only concern was, some folks had the
perception of that this doesn't seem to work in practical scenarios,
hence would not worth the efforts. That's why I thought of posting
this idea here to grab some general consensus is it worth stabbing.

Regarding authorizations, I wish it would be possible to have an
optional role to be attached with the User object (or subject to be
authenticated) and then its being passed on to application to
implement the permission logic. Also, we could even have route level
authorizations based on the role. For example route to /admin/* paths
can be blocked off from the rack layer itself if the user doesn't have
administrative privileges. Or SSL encryption could be offered only to
selective set of users (i.e. paid users) based on their role. Yet as
you say it doesn't need to be restricted only with roles or
permissions only.

Anyway thank you for clearing the mist.

Best Regards,
Lakshan

On Apr 1, 5:12 am, Daniel N <has....@gmail.com> wrote:
> On Wed, Apr 1, 2009 at 10:41 AM, Daniel N <has....@gmail.com> wrote:

[Daniel N]

Hi Lakshan,

Please hit me in IRC: hassox or on skype at the name I gave you previously.  There is talk on the GSOC list of needing to get proposals into the system asap and I'd like to talk to you about getting this one sorted.  There is interest in it, lets work out what a proposal can be with the current state of things.

Cheers
Daniel

[Yehuda Katz]

I think that the general impression that it can't be generic is a misunderstanding of what an auth/authz system would need to be. In general, a good auth system provides an API for building strategies or policies, and components that are dependent on the system would use an agnostic API to interact with it. The trick is making that work.

I think we did a reasonably good job in Merb, but Rack::Auth is even better :)

-- Yehuda

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325