I committed this change in r10318. Please update your security files. I'll begin work on the documentation in the wiki now...
Josh On Wed, Apr 13, 2011 at 6:21 AM, Josh Holtzman <[email protected]>wrote: > 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] _______________________________________________
