The technology is pretty simple, actually. The current approach is to define an Organization (.java, in case you're searching the source code), and to set the current Organization just like we set the current User, via a servlet filter (OrganizationFilter.java). The URI requested determines the organization, much like a virtual host in an apache httpd configuration.
The SecurityService (again, .java) can be used to look up the current user and org during the lifecycle of an HTTP request, or it can be used to set the user and org context for a long running, asynchronous thread that is not bound to an HTTP request. The trunk is already doing this in each place where new threads are started or recycled from a thread pool: running workflows that have been waiting in a queue, ingesting from an inbox, etc. What's left is teaching each service about orgs and roles, so when a user asks for a list of capture agents, for example, the query executed looks more like "select * from capture_agents ca where ca.org=:current_org and ca.role in (:current_user_roles)" than "select * from capture_agents". This way, a user sees only those capture agents belonging to their organization, and further, only those that they are allowed to see. How we expose the authorization options is still an open question, but this doesn't have to be addressed for 1.2, I think. Simply limiting access to specific local roles (e.g. admin) is probably a good first step. Sound reasonable? Josh On Tue, Apr 12, 2011 at 5:27 PM, Christopher Brooks <[email protected]>wrote: > Josh, > > What's the best search keyword to understand the technology being used > here better? > > Chris > > On Tue, 12 Apr 2011 17:22:08 -0500 Josh Holtzman > <[email protected]> wrote: > > > A couple of weeks ago, Tobias and I committed the basic code and > > services that allow Matterhorn servers to support role based > > authorization of users from multiple tenants, or organizations. > > There's a lot left to do to support authorization and multitenancy, > > but I've got a patch ready to commit that tackles the authentication > > piece. This patch adds the ability to specify separate security > > configuration files for each tenant. The change involves moving > > $FELIX/conf/security.xml to $FELIX/conf/security/mh_default_org.xml > > (where 'mh_default_org' is the identifier of the default, and > > currently only, tenant in a default installation). > > > > I'll make the commit in the next couple of days so if you are working > > on the trunk, please be aware that you'll need to update your felix > > conf directory. > > > > Thanks, > > Josh > > > > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
