source: trunk/doc/historical/specifications/core/accesscontrol.html @ 4509

Last change on this file since 4509 was 4509, checked in by Jari Häkkinen, 15 years ago

Addresses #1106. Missed to change reference wherefrom retrive GPLv3 license text. And some other changes.
  • Property svn:eol-style set to native
  • Property svn:keywords set to Id Date
File size: 9.9 KB
Line 
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2<!--
3  $Id: accesscontrol.html 4509 2008-09-11 20:01:44Z jari $
4
5  Copyright (C) 2005 Jari Hakkinen, Nicklas Nordborg
6  Copyright (C) 2006 Jari Hakkinen
7
8  This file is part of BASE - BioArray Software Environment.
9  Available at http://base.thep.lu.se/
10
11  BASE is free software; you can redistribute it and/or
12  modify it under the terms of the GNU General Public License
13  as published by the Free Software Foundation; either version 3
14  of the License, or (at your option) any later version.
15
16  BASE is distributed in the hope that it will be useful,
17  but WITHOUT ANY WARRANTY; without even the implied warranty of
18  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
19  GNU General Public License for more details.
20
21  You should have received a copy of the GNU General Public License
22  along with BASE. If not, see <http://www.gnu.org/licenses/>.
23-->
24<html>
25  <head>
26    <title>BASE - Core specification - Access control</title>
27  <link rel=stylesheet type="text/css" href="../../styles.css">
28  </head>
29<body>
30
31<div class="navigation">
32  <a href="../../index.html">BASE</a>
33  <img src="../../next.gif">
34  <a href="index.html">Core specification</a>
35  <img src="../../next.gif">
36  Access control
37</div>
38
39  <h1>Access control</h1>
40
41  <div class="abstract">
42    <p>
43    This document covers the details of how to control who may access a given
44    item and/or function in BASE.
45    </p>
46
47    <b>Contents</b><br>
48    <ol>
49    <li><a href="#access">Access control</a>
50    <li><a href="#items">Access to items</a>
51    <li><a href="#role">Role-based access</a>
52    <li><a href="#project">Project-based access</a>
53    </ol>
54   
55    <b>See also</b><br>
56    <ul>
57    <li><a href="../../development/overview/data/authentication.html">Implementation overview</a>
58    </ul>
59
60    <p class="authors">
61    <b>Last updated:</b> $Date: 2008-09-11 20:01:44 +0000 (Thu, 11 Sep 2008) $
62    </p>
63  </div>
64
65  <h2>Summary</h2>
66 
67  Access to an item can be granted by four different ways:
68
69  <ol>
70  <li>By being the owner of the item.
71  <li>By being a user or member of a group that has been allowed access to the item
72    by it's owner.
73  <li>By being a member of a role that allows access to items of that type.
74  <li>By being a member of a project where the item is used.
75  </ol>
76
77  The final access permission is given by the combined permission of the four
78  paths above.
79
80  <a name="access">
81  <h2>1. Access control</h2>
82  </a>
83
84  <ol>
85  <li>Access control in BASE always works in the same way, not depending
86    on if internal or external authentication is used.
87
88  <li>Access control is enforced for all operations in BASE, for example
89    creating new items, accessing existing items, and other operations
90    not involving any particular item.
91  </ol>
92
93  <a name="items">
94  <h2>2. Access to items</h2>
95  </a>
96
97  <ol>
98  <li>If the item has an owner, the owner always has full access.
99
100  <li>Items that don't have an owner can only be accessed by role-base
101    permissions (see <a href="#role">below</a>).
102
103  <li>Items that have an owner can be shared to other users and/or groups with
104    individual permissions assigned to each user/group.
105    The following permissions levels are defined:
106    <ul>
107    <li>read: the user may read information about the item
108    <li>use: the user may use the item, ie. reference it from
109      other items which may include modifying some information
110      (for example decrease the remaining quantity of a biomaterial)
111    <li>write: the user may update information about the item
112    <li>delete: the user may delete the item
113    <li>set owner: the user may change the owner of the item
114    <li>set permissions: the user may change which users and groups have access
115      to the item
116    </ul>
117    <div class="question">[QUESTION] Some permissions are not very useful unless they appear together,
118      for example "use" implies that a user also has "read" access. Should this be
119      enforced by the core, or is it up to the client to supply the "correct"
120      combinations?<br>
121      Answer: A consistent behaviour is always desired, ie. the core should make those
122      restrictions.
123    </div>
124
125  <li>Users should be able to create a named, predefined set of users and/or groups
126    with given permissions. We call this set a "key" (hmmm...not very logical in
127    this context).
128
129  <li>While assigning permissions to an item, such a key may be used. If the key is
130    changed at a later time, the permissions to access the item should reflect
131    this change.
132
133  <li>If a user receives permission from several paths (individually, by group
134    membership, by role membership or project membership), the permissions are combined.
135    For example, if a user has individual "read" permission and is a member of a group with
136    "update" permission the user has both "read" and "update" permission.
137
138  <li class="question">[QUESTION] What about a "deny" setting to revoke permissions?
139    For example, a group is assigned "read" permission, but for one of the members we
140    want to revoke that permission. On the other hand, how is it decided if "deny"
141    or "read" permission should win? Another example, a group is assigned "deny"
142    permission, but we want to give one of the members "read" access.
143    One solution would be to always let the most specific setting win:
144    <ol>
145    <li>Check ownership
146    <li>Check if shared/denied to user
147    <li>Check if shared/denied to group
148    <li>Check if shared/denied to role
149    <li>Check if shared/denied to project
150    </ol>
151    Some systems has the policy that if a "deny" setting is present, it always
152    wins.
153
154  </ol>
155 
156  <a name="role">
157  <h2>3. Role-based access to items</h2>
158  </a>
159 
160  <ol>
161  <li>Roles are used for assigning permissions to *all* items of a specific type.
162    Roles cannot be used for assigning permissions to individual items.
163    The same access levels as specified for users/groups above are used, plus
164    two new ones:
165    <ul>
166    <li>create: the user may create new items of the specified type
167    <li>deny: the user may not access or modify any item of the specified type
168    </ul>
169
170
171
172  <li>Roles can be assigned permissions for other system-wide operations
173    not involving any particular item, for example shutting down BASE.
174
175  </ol>
176
177  <a name="project">
178  <h2>4. Project-based access to items</h2>
179  </a>
180
181  <ol>
182  <li>Projects are used to gather items of (almost) any type into
183    a single collection.
184
185  <li>An item has a "project permission" setting that specifies the maximum
186    permission level within the context of the project.
187
188  <li>An item can be used in zero, one or more projects with different permissions.
189
190  <li>Users and groups can be members of zero, one or more projects with different
191    permissions.
192
193  <li>Users and groups can be assigned a generic permission level that applies
194    to all items in the project.
195
196  <li>The permission for a user to access an item via the project is calculated by comparing
197    the item's project permission with the user's generic permission, and
198    only allowing actions that are common for both permissions. For example,
199    a user has "read" and "write" generic permissions to a project, but an
200    item only has "read" permission. The resulting permission is "read".
201    Of course, ownership and direct sharing with users/groups also have
202    to be considered.
203
204  <li>A user may select to work with a project. All items created are then
205    automatically added to the project with full permissions.
206
207  <li>Items can be manually added or removed from projects. The project
208    permission may also be modified.
209
210  <li>Adding an item to a project requires at least "use" access to
211    the item and project. The "project permission"
212    for the item cannot be set higher than the access permission to the item.
213
214  </ol>
215
216  <!--
217  <a name="implementation">
218  <h2>5. Implementation overview</h2>
219  </a>
220
221  <h3>5.1 Database schema</h3>
222  <p>
223  <img src="images/accesscontrol.gif">
224  </p>
225
226  <p>
227  Several tables have a <span class="incode">permission</span> column.
228  It should an integer column with at least 16 bits. The bits have the following
229  meaning:
230  </p>
231
232  <table cellpadding=2 cellspacing=0 border=1>
233  <tr>
234    <th>Bit</th>
235    <th>Value</th>
236    <th>Permission</th>
237  </tr>
238  <tr>
239    <td>0</td>
240    <td>1</td>
241    <td>READ</td>
242  </tr>
243  <tr>
244    <td>1</td>
245    <td>2</td>
246    <td>USE</td>
247  </tr>
248  <tr>
249    <td>2</td>
250    <td>4</td>
251    <td>WRITE</td>
252  </tr>
253  <tr>
254    <td>3</td>
255    <td>8</td>
256    <td>DELETE</td>
257  </tr>
258  <tr>
259    <td>4</td>
260    <td>16</td>
261    <td>CREATE</td>
262  </tr>
263  <tr>
264    <td>5</td>
265    <td>32</td>
266    <td>SET OWNER</td>
267  </tr>
268  <tr>
269    <td>6</td>
270    <td>64</td>
271    <td>SET PERMISSION</td>
272  </tr>
273  <tr>
274    <td>7</td>
275    <td>128</td>
276    <td>DENY</td>
277  </tr>
278  </table>
279
280  <h3>5.2 Keys</h3>
281
282  <p>
283  A key is something that contains information about the permissions
284  to access an item. There are four types of keys:
285
286  <ol>
287  <li>SYSTEM: This key type gives access to systemwide operations, for example
288    to shut down the BASE server. This type of key can only be given to
289    roles.
290
291  <li>CLASS: This key type applies to all items of a specific type, and can
292    only be given to roles.
293
294  <li>ITEM: This key type applies to a specific item (key_id column). It can be given
295    to users and groups.
296
297  <li>PROJECT: This key type also applies to a specific item (projectkey_id column).
298    It is used for sharing items to projects.
299  </ol>
300
301  <p>
302  After a user has been authenticated all keys for that user is loaded
303  and sorted by id in an array. To begin with keys from the <span
304  class="incode">UserKeys</span>, <span class="incode">GroupKeys</span>
305  and <span class="incode">RoleKeys</span> are loaded.
306  If the user selects to work with a project the keys from <span
307  class="incode">ProjectKeys</span> are also loaded. Checking for permission
308  to access an item is then as easy as searching for the keys (key_id,
309  projectkey_id and a CLASS key) in the sorted arrays.
310  </p>
311
312  <p>
313  To keep the number of ITEM and PROJECT keys down, they are reused.
314  The same combination of users, groups and permissions should not
315  be present in more than one ITEM key, and the same combination of
316  projects and permissions should not be present in more than one
317  PROJECT key. The only exception is if the ITEM key is a named key.
318  Then, it doesn't matter if other keys also has the same combination.
319  The reason is that the user may change the named combination at any
320  time.
321  </p>
322  -->
323</body>
324</html>
Note: See TracBrowser for help on using the repository browser.