Ticket #23 (new task)

Opened 10 months ago

Last modified 7 months ago

Implement ACLs

Reported by: mahlon Assigned to: mgranger
Priority: major Milestone: ThingFish 0.3 - The "N-Robot" Release
Component: ThingFish Keywords: thingfish acl access-control
Cc: Depends on: 41

Description (Last modified by mahlon)

This needs a considerable amount of fleshing out and discussion still.

At a minimum, a base ACL filter that can intercept and return 401/403.

Should be able to look up the actual usernames and passwords from arbitrary sources. ThingFish::Authenticate? Some default supplied classes:

  • Flat file
  • LDAP
  • The MetaStore itself

Later -- how to provide ACLs per resource - who's got read/write, how granular do we go (ACLs on metadata triples?)

If a user doesn't have read access to a particular resource, and a new upload would checksum match, need to upload anyway to avoid information leaking. Probably a lot more info leak kinds of paths to consider, as well.

Change History

11/30/07 09:41:58 changed by mahlon

  • description changed.

(filter, not handler.)

11/30/07 11:32:16 changed by mgranger

Some notes that I'm braindumping here for lack of a more-relevant place:

Since filters are plugins, something like:

class ThingFish::AuthFilter < ThingFish::Filter
    include ThingFish::AbstractClass
    
    virtual :authenticate_user
    
    def handle_request( request, response )
        # Put most of the real guts of the auth system here, 
        # and grab the user and any relevant group info from the
        # abstracted #authenticate_user when appropriate.
    end
end

class ThingFish::HtpasswdAuthFilter < ThingFish::AuthFilter; end
class ThingFish::LDAPAuthFilter < ThingFish::AuthFilter; end
class ThingFish::MetastoreAuthFilter < ThingFish::AuthFilter; end

Also, the filter should just do authentication, not authorization. Authorization can be done abstractly as long as the authentication systems populate the same fields in the request like authenticated_user, user_groups, etc. Doing it this way has several benefits:

  • You can swap out auth systems transparently -- all per-object permissions should still work.
  • It would allow a specialized plugin to combine several auth layers, allowing us to, for instance, allow external users to download stuff without them having to be in LDAP.
  • Way easier to test, eliminate edge cases, information leaks, etc.

Authorization should be a handler, I think, since it will almost certainly need access to the metastore. That will also allow us to have separate auth systems for /«uuid», /admin, etc.

03/19/08 07:23:47 changed by mahlon

  • depends_on set to 41.