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:[email protected]] Sent: Montag, 22. März 2010 18:27 To: [email protected] 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 <[email protected]>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:[email protected]] > Sent: Montag, 22. März 2010 15:13 > To: [email protected] > 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 > >
