Current Features
----------------

Currently, GEAS does not implement any significant security. However,
provided only trusted clients have access to the server, this may be
sufficient. (Currently, all activities on data objects may be logged, which
can be useful in some situations. However, object references may be forged
be a sufficiently knowledgable programmer with access to the server.)

The following paragraphs describe how to manage users in the object server,
for developers writing admin tools. In the future, GEAS will restrict
certain operations on geas::user instances to authorised administrator
users, while general users will be given restricted access to their own
records and no access to other records.


Creating new users:

    Create a new geas::user object. Set the username and password to
appropriate values (with no encryption on the password - store plain text.)


Changing passwords:

    Use Connection.loadSingleObject() to locate the geas::user object, and
set the password to a new value.


Deleting users:

    Use Connection.loadSingleObject() to locate the geas::user object, and
delete it.



Future plans
------------

Implement real security  :)
  - Control all data access
  - Restrict access by class and by instance
  - Possibly manage per-field access

Use the CORBA security service to provide encryption of network traffic and
manage non forgeable object references.

Assign rights to specific user groups/user classes/user types. A given user
will have their access specified as matching that of a set of groups. (ie,
if a user belongs to three groups, then that user will have access to
anything permitted to one or more of those groups, and no access only to
items denied to all of those groups.)

Possibly allow per-user tweaking of access rights.

Allow a user to temporarily request more access for short periods of time.
(eg: a normal user needs to add another user to the system. he requests
admin rights (and provides the appropriate password) and temporarily has the
access rights of the admin user. Once finished, admin rights can be
relinquished. this is traditionally useful for such admin operations, where
the more powerful rights aren't needed often, and this method means the user
is less likely to leave the client running with excessively open rights.
Look at documentation on Linux user ids for more examples.)


