Re: [Gnue-dev] Appserver/Common Issues

[Robert Jenkins]

Hi guys,
A few thought re. security features.


Security and access control are very important, but please don't go to
impractical levels.

The most vulnerable part of the system is the database itself - unless
you are going to encrypt all stored data, there is nothing to stop
someone with either physical or program access to the database server
from reading what they like.

The security for that side of things is mainly down to the administrator
of the system.

For 99% of users, the critical parts of security are down to being able
to log in to the application and view / edit appropriate fields as
defined by the application's author & the site admin - and not see the
parts that should be restricted.

Presumably the usernames & passwords will be stored in the main
database, so the program must have a built-in or configured 'fixed'
password to be able to verify user logins (and create a fixed
'superuser' login when initially installed to allow users to be added by
the system admin?). 
Remember GNUe is supposed to be a cross-platform application, with
Windows 98 etc. systems as possible clients. You cannot assume security
at the client O.S. level!


It seems to me that the 'user' security must be based in the application
+ database.


All the business apps I've worked with have been based on either:

'user level', with each form or field allocated a numeric level, & only
visible /  editable to the user if that user's security level is >= to
the form or field level, or

User-group type Bitmasks - each user has (e.g.) a 32 bit security mask
which enables viewing or editing for forms / fields with matching bits.

Whatever actual mechanism you use, it needs to allocate a value to the
user when they log in to the system. The extensions to these schemes
that would be useful are some form of  'permitted terminals' system
(i.e. on the basis the chief accountant shouldn't be logging in at Goods
Inwards), timed lockout for multiple login errors (to prevent hacking)
and logging / email notification to the system admin of login errors. 


Having multiple forms for different levels is just not practical for a
serious application. The forms and fields need attributes to control
viewing and editing, so in-appropriate items are either read-only or
completely hidden from users.

The Visual effect should be that each 'user level' gets their own
tailored form - but achieved by the system from the standard definition
of that form.

Don't forget this applies to labels as well, it's a bit of a give away
that things are being concealed if the numbers are hidden but the labels
are still displayed.

Regards,

Robert Jenkins,
JRW.