incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Innerhofer <manuel.innerho...@trialox.org>
Subject Re: Permission naming convention for using an application
Date Tue, 23 Mar 2010 09:47:41 GMT
Recently I changed the default clerezza instance configuration:
- I added a new graph called "configuration" graph. It contains
information used to configure the platform. These information are not
sensitive, therefore could be read by anybody, but should only be
modified by users having the right to configure the platform.

On Tue, 2010-03-23 at 09:10 +0100, Reto Bachmann-Gmuer wrote:
> You're right Marco, the comparison with the filesystem is falls short as in
> a hierarchical filesystem there's a nesting the permission system can take
> advantage of. In that graphs are like roots, even though they are named and
> permissions can be assigned using wildcard expressions on the name of the
> triplecollection.
> 
> Clerezza is meant to be used with multiple graphs and the foremost reason to
> split data into multiple graphs is that different parts of the data shall be
> accessible by different groups of users. Uniongraph allow a user to see the
> different graphs they have access to as one graph. The content graph as
> returned by the content graph provider is such a union graph, this allows
> for more data to be included when the user has more access rights. I was
> thinking if it would be a good idea to change the set of graphs that
> constitute the union content graph depending on the path(-prefix) of the
> webrequest.
> 
> By default a clerezza instance is configured as follows:
> - The system graph is accessible only by the admin user
> - The content graph is world readable
> - Users with the role CommunityUser have read-write rights to the graphs
> matching the pattern "http://tpf.localhost/user/{username}/*"
> 
> @manuel: could you add the newly created graphs and roles?
> 
> Cheers,
> reto
> 
> 
> On Mon, Mar 22, 2010 at 6:38 PM, Marco Zaugg
> <marco.zaugg@getunik.com>wrote:
> 
> > Ok, taking your Graph-Level example with the comparison to the filesystem,
> > you're basically talking about giving each user full read/write access to
> > the root directory, although various users would just require read/write
> > access to
> > a subfolder?
> >
> > If that is what you're saying, shouldn't there not be multiple graphs
> > similar to subdirectories on fileservers in order to control who has access
> > to which part of the content structure?
> >
> > Or am I just too stupid to see the obvious?
> >
> > -----Original Message-----
> > From: Reto Bachmann-Gmuer [mailto:reto.bachmann@trialox.org]
> > Sent: Montag, 22. März 2010 18:27
> > To: clerezza-dev@incubator.apache.org
> > Subject: Re: Permission naming convention for using an application
> >
> > Rougly I'd say are 3 levels of permission restrictions.
> >
> > Graph-level: This is the most important level, it defines who can read and
> > who can write to a triple collection. This can be compared to the access
> > rights on a filesystem. It is not possible to grant or restrict permissions
> > on subgraphs via this mechanism. The reason for this, is that such a
> > feature
> > would require operations of potentially non polynomial complexity on every
> > access to the graph and is thus perfomance-wise a non-option.
> >
> > Service-Level: A service can do stuff for a user they potentially could not
> > do directly on the graph. This is comparable to the sudo feature on a unix
> > machine. Using a service a user might for example get a list of users from
> > the system-graph without having read-write to the system graph. Services
> > can
> > be accessible via OSGi and/or via REST.
> >
> > App-Level:  On this level a user is prevented from using an application, of
> > course the user could also be prevented from using the application by not
> > having the respective Graph- or Service-level permissions, but in some
> > situations one would simply like to prevent the user from being able to
> > access features that might confuse them. In analogy in unix is the execute
> > permission on a file.
> >
> > On Mon, Mar 22, 2010 at 6:00 PM, Marco Zaugg <marco.zaugg@getunik.com
> > >wrote:
> >
> > > Do I get that correct, although a user doesn't have a 'AppPermission'
> > > to access, say the application front-end of the 'User Manager', he/she
> > > could still access and
> > > manipulate the graph through a script using the REST API?
> > >
> > > IMO this is not correct. A front-end application could consist of
> > > different permissions, i.e. read/write access on a specific part of
> > > the main content graph, or can access and open the application front-end.
> > >
> > > With this, a user could get read/write access on a graph without the
> > > app front-end. Could also have both, App front-end access and graph
> > > CRUD permissions. But could not have just the App permission without
> > > having the permission to manipulate the graph. It's like a OSGI bundle
> > > that needs another bundle in order to properly work.
> > >
> > >
> > > -----Original Message-----
> > > From: Manuel Innerhofer [mailto:manuel.innerhofer@trialox.org]
> > > Sent: Montag, 22. März 2010 15:13
> > > To: clerezza-dev@incubator.apache.org
> > > Subject: Permission naming convention for using an application
> > >
> > > Hi all,
> > >
> > > Reto and I have discussed how to name permissions that gives a user
> > > permission to use an application front-end. This means even though the
> > > user has all permissions needed to use the functionality provided by the
> > > application (like modifying a graph etc.), she still can't access its
> > > front-end.
> > >
> > > We came up with the convention that the permission name should end with
> > > "AppPermission". For example the permission needed to access the script
> > > manager has the name "ScriptManagerAppPermission".
> > >
> > > Cheers,
> > > Manuel
> > >
> > >
> >



Mime
View raw message