source: trunk/doc/historical/specifications/core/authentication.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: 12.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: authentication.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 - User authentication and management</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  User authentication and management
37</div>
38
39  <h1>User authentication and management</h1>
40
41  <div class="abstract">
42    <p>
43    This document covers the details of internal and external user authentication.
44    It also discusses user management and how groups and roles are related.
45    </p>
46
47    <b>Contents</b><br>
48    <ol>
49    <li><a href="#authentication">User authentication</a>
50    <li><a href="#user">User management</a>
51    <li><a href="#group">Group management</a>
52    <li><a href="#role">Role management</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  <a name="authentication">
66  <h2>1. User authentication</h2>
67  </a>
68
69  <ol>
70  <li>A user is authenticated by a unique login name and a password.
71
72  <li>BASE can be configured to use internal or external authentication.
73
74  <li>Support for external authentication is provided by standardized plugin
75      modules that can be added to BASE independently of the core system.
76
77  <li>If the technical solution allows it, internal authentication may also be
78    implemented as a plugin.
79
80  </ol>
81
82  <h3>1.2 Internal authentication only</h3>
83  <ol>
84  <li>BASE maintains a list of valid login/password combinations.
85  <li>It should be possible to set an expiration date for a user
86    account, after which the user will not be able to log on to BASE.
87  </ol>
88
89  <h3>1.3 External authentication only</h3>
90  <ol>
91  <li>The primary role of the external authentication system is to accept or reject
92    the login/password combination.
93
94  <li>If the user is accepted, the authentication system should return a
95    unique ID identifying the user. The ID must always be the same.
96    The uniue ID may be the same as the login name, but doesn't have to.
97
98  <li>BASE maintains a list of known unique IDs.
99
100  <li>Optionally, BASE can be configured to cache the login/password combinations.
101    This will make it possible to log on to BASE even if the external
102    authentication system currently is unavailable. It should also be possible
103    to limit the time the cached data is valid. The limit may be infinite.
104
105  <li class="question">[QUESTION] What about single-sign-on systems for external authentication?
106    If a user is logged in, can this information be carried on to BASE? This would
107    affect point 1.1 since a user can be authenticated by something else than a
108    login/password combination, for example a cookie.<br>
109    Answer: This is difficult and depends on the client application. For example, a web
110    based authentication system may use a cookie, which cannot be used by
111    standalone applications. In other words, this cannot be a core feature.
112
113  <li>Account expiration handling should be done by the external system,
114    BASE should not enforce any time limit when using external authentication.
115
116  </ol>
117
118  <a name="user">
119  <h2>2. User management</h2>
120  </a>
121
122  <ol>
123  <li>BASE maintains additional information about a user,
124    ie. email address, phone number, etc.
125
126  <li>The only required information about a user is the login name
127    and the full name.
128
129  <li>Preferrably, the email address should also be known.
130  </ol>
131
132  <h3>2.1 Internal authentication only</h3>
133  <ol>
134  <li>User accounts can be manually created, updated or deleted by an
135    administrator.
136   
137  <li>Users may update their own information, except the login name and
138    the full name.
139
140  <li class="client">[CLIENT] A client application may allow self-registration.
141    The privileges
142    initially assigned to such an account should be configurable. The normal
143    configuration would be to allow less than for a normal account. Note!
144    The client application must of course be logged in with permission to
145    create user accounts.
146  </ol>
147 
148  <h3>2.2 External authentication only</h3>
149  <ol>
150  <li>The external authentication system may, but is not required to, provide
151    additional information, ie. email address, phone number, etc., about the user.
152
153  <li>If the authentication system doesn't provide a full name, the full name
154    is set to the same value as the login.
155
156  <li>If a user not formely known to BASE is logging in and is accepted by the
157    external system, a new account is created, including any available
158    additional information. BASE can be configured to automatically
159    add a new user to a specific group and/or role.
160
161  <li>If the external system provides additional information, BASE can be configured
162    to automatically update changes to the information. This is done at
163    login time.
164   
165  <li>If the external system provides additional information, BASE can be configured
166    to advice client application to disallow changes to that information. A
167    client application is not required to follow that advice. Note! This is because
168    we want to allow batch updates for synchronizing information between the
169    external system and BASE (see the <a href="#batch">Batch processing</a> section).
170
171  <li>If a user already known to BASE is rejected by the authentication system,
172    the account should be flagged as deleted.
173
174  <li>It is still possible to create, update or delete existing accounts in BASE,
175    but that information is not verified against the external system. Note! This
176    is because we want to allow batch updates for synchronizing information
177    between the external system and BASE (see the <a href="#batch">Batch processing</a>
178    section).
179
180  <li>BASE can only query the external system for information. Information
181    in the external system cannot be created, modified or deleted.
182   
183   
184  <li class="client">[WEB CLIENT] If a user not formerly known to BASE is accepted by the
185    external system, one of the following may happen:
186    <ul>
187    <li>If the external system doesn't supply additional information, the user
188      is presented with a form to add that information manually.
189    <li>If the external system supply additional information and BASE is configured
190      to allow modifications, the same form as above is shown, but with the
191      supplied values already entered.
192    <li>If BASE is configured not to allow modifications to the additional
193      information the values supplied by the authentication system are stored and
194      the login proceeds as normal.
195    </ul>
196    The web client should respect the advice to not allow modification to
197    additional information.
198
199  <li class="client">[OTHER CLIENT] If a user not formerly known to BASE is accepted by the
200    external system, the client may choose to reject the user access to BASE.
201    If the client rejects the user it should let the user know about another
202    client application, for example the web client, that can be used to
203    enter BASE for the first time.
204  </ol>
205 
206  <a name="batch">
207  <h3>2.3 Batch processing</h3>
208  </a>
209  <ol>
210  <li>Batch processing is allowed for both authentication types.
211
212  <li>User accounts can be added, updated or deleted in batch by uploading
213    a formatted file containing the user information. How the file should
214    be formatted is not specified by BASE, but by standardized plugin modules.
215    Such modules can be added to BASE independently of the core system.
216
217  <li class="note">[NOTE] Another way to implement batch updates is to make a
218    client application
219    that uses the BASE API. Such a program may, for example, be scheduled for
220    nightly runs to synchronize information between BASE and an external system.
221  </ol>
222
223
224  <a name="group">
225  <h2>3. Group management</h2>
226  </a>
227
228  <ol>
229  <li>Groups are used for organising users into units. Usually this maps into
230    real-world groups, for example, "lab group 1", "lab group 2", etc. Groups
231    are used in the access control mechanism to control access to individual,
232    existing items (see the <a href="accesscontrol.html#items">Access to items</a>
233    section).
234
235  <li>Groups are added, updated and deleted by an administrator.
236 
237  <li>Users are assigned to groups by an administrator.
238
239  <li>A user that is a member of a group may see information about
240    other members.
241
242  <li class="question">[QUESTION] What about groups and external authentication systems?
243    Should BASE allow such systems to also provide group information. In that case,
244    can the external system also provide group membership information?
245    How is this information synchronized?
246    <br>
247    Answer: No
248
249  <li class="question">[QUESTION] What about groups within groups?
250    <br>
251    Answer: Yes, this would be a nice feature. But only if it can
252    be implemented in a relatively simple way.
253
254  <li class="question">[QUESTION] Batch updating of group information?
255    <br>
256    Answer: Yes. This can the be used to synchronize external systems with BASE.
257
258  </ol>
259
260  <a name="role">
261  <h2>4. Role management</h2>
262  </a>
263
264  <ol>
265  <li>Roles are used for organising users by function and responsibility,
266    for example, server administrators, head of the lab, regular user,
267    reviewer, etc. Roles are used in the access control mechanism to control
268    access to all items of a specific type and other operations not involving
269    any particular items (see <a href="accesscontrol.html#role">Role-based
270    access to items</a> section).
271
272  <li>Roles are added, updated and deleted by an administrator.
273
274  <li>Users are assigned to roles by an administrator.
275
276  <li class="question">[QUESTION] What about roles and external authentication systems?
277    Should BASE allow such systems to also provide role information. In that case,
278    can the external system also provide role membership information?
279    How is this information synchronized?
280    <br>
281    Answer: No
282
283  <li class="question">[QUESTION] What about roles in groups?
284    <br>
285    Answer: Hmm... what does this really mean? Answer is no.
286
287  <li class="question">[QUESTION] What about "group roles"? Ie. users that have a special
288    role within a group, for example, "leader of lab group 1". Such a user
289    could for example have access to everything that is produced by
290    members of the group. It should also be possible to have different roles
291    in different groups.
292    <br>
293    Answer: Not optimal. What if a user is a member of two groups, then some things
294    are actually only for group 1 and some things only for group 2?
295    Can the introduction of "projects" avoid this? By adding items and
296    permissions to projects it might be possible to get generic permissions
297    for all items within a project.
298   
299  <li class="question">[QUESTION] Batch updating of role information?
300    <br>
301    Answer: Yes...
302  </ol>
303
304  <!--
305  <a name="implementation">
306  <h2>5. Implementation overview</h2>
307  </a>
308
309  <h3>5.1 Database schema</h3>
310  <p>
311  <img src="images/authentication.gif">
312  </p>
313
314  <p>
315  The <span class="incode">Passwords</span> table is used
316  for internal authentication only and stores login/password
317  combinations. A password is stored in an encrypted form
318  given by calculating the MD5 hash of the password.
319  </p>
320
321  <p>
322  The <span class="incode">Users</span> table stores the additional
323  information for each user, including the external ID if external
324  authentication is used.
325  </p>
326
327  <h3>5.2 External authentication</h2>
328
329  <p>
330  For external authentication we define the <span class="incode">Authenticator</span>
331  interface. It has three methods:
332  </p>
333
334  <dl>
335  <dt>init(settings)</dt>
336  <dd>Initialises the object. The settings parameter is string whose format
337    is specified by the plugin implementation. For example it might be the
338    host name of the authentication server or the url for a database
339    connection. The BASE core doesn't care about the format.
340
341  <dt>supportsExtraInformation()</dt>
342  <dd>Returns TRUE if the authentication system returns additional
343    user information (ie. address, phone, email, etc). Otherwise FALSE
344    should be returned.
345
346  <dt>authenticate(login, password)</dt>
347  <dd>Tries to authenticate the login/password combination. If it is
348    successful the unique ID is returned together with additional
349    information if supported. If the authentication fails an error
350    is thrown.
351
352  </dl>
353
354  <p>
355  If the external authentication doesn't support additional information
356  the name of new users is set to the login.
357  </p>
358  -->
359
360</body>
361</html>
Note: See TracBrowser for help on using the repository browser.