[Adept Open Source Library] User Management

[Paul Marrington]

Adept is a browser-based system. As such it is inherently multi-user. With more than one operator, the need for user management becomes manifest. The Adept Library provides this support with a User object - a persistent DAO. The User object contains a name and password for authentication. Authentication is not enough. Any system that needs user management needs a concept of authorisation. Who can access which form. Who can update which data. Adept provides this functionality with the concept of groups. The system holds persistent one list of group names in the object User.Groups. The User.Groups object is quite literally and simply an array of string group names. The User object keep an array of indexes to groups the user belongs to. Groups can be added but not deleted. Actually there is an exception. If a user is added and deleted immediately, their personal group is removed. When a new user is created, a group of the same name is also created. They are automatically joined to the groups Everybody and the one with their own name. A newly created system will automatically create users and groups with the names Everybody and Administrator. It is a good idea to give both these users passwords as soon as practical. How is it used? The system requires that someone be logged in at all times. It can be configured to ask or to default to Everybody for an open interface. The log-in can be told to 'stick' so that the user need only log in once on a single system. The Adept user is for authorisation and convenience, not high security. Use the client operating system for that. For this reason there is no user time-out. The User object for the current user is attached to the session. The menu system, for example, limits display of selections by group names. Only users in the group Administrator, for example, can open the page to add or administer users and groups. In a similar manner, tree nodes can be set to be hidden or unopenable for users not is a specific set of groups. Finally, edit components can be forced to hidden or read-only mode. Lastly, all applications have a group. The list of available applications on the main desktop will only include those that the current user is in the group for. So, when creating an account for Sally, make sure that she is in the Accounts group if she is to open the accounts system.

--
Posted By Paul Marrington to Adept Open Source Library at 8/31/2007 11:59:00 AM

[Paul Marrington]

I am using Adept Bookings as a proof-of-concept system for the Adept Development System. The first thing that became immediately obvious was that now it is time to implement user management. Authentication Adept user management provides authorisation, not full authentication. So, let's start with talking authentication. Authentication is to stop unauthorised access. It typically involves log-in and some sort of time-out so that a workstation locks if left unused. These functions are best done by the operating system. Adept supports operating system authentication by allowing you to stay logged in on any user account on any hardware. Use the optional check-box for this function. Once checked then any time you go to Adept in the future you will continue where you left off. Only your user account will have this ability - so security requirements are covered. With fast user switching (available on Windows XP/Visa, OS X and some Linux distributions), we end up with a powerful and easily shared system. As each person moves away and the screen-saver kicks in, the next user will need to switch to their account. If they have Adept running it will still be available for use - exactly where they left it. This works well in a shared front-desk situation. If you want more security, add a swipe or proximity card to the mix. Installation and maintenance are an operating system task and independent of Adept. First Start When a virgin system is created - and the installation does not create a special system - then two users/groups are created - Administrator and Everybody. Both can be logged in and neither has a password. Only Administrator can create or lock out users - or change groups. Log in as Administrator and create users for all people who will use the system. Give then access to the groups that will be named after the applications they are using. First Log-in The first time you go to Adept on a new system you will be presented with a log-in screen. If the application is single-user, choose the user you maintain and set it to stay logged in. You will not be bothered again. If more than one person use the system the the administrator will have created user names to suite. Resist working as Administrator or the user with the same name as the application unless absolutely necessary. Authorisation Once logged in the user object is attached to the session. Each user belongs to two or more groups. Various components recognise groups and change functionality accordingly.

1. Menu: Menu items can be displayed or hidden based on use groups. If the node element
2. element has a groups attribute, then only users in those groups will see this menu item.
3. Applications: The Desktop menu has an Application item. Valid applications are in the configuration files. Any PROPERTIES.TXT in any META-INF can have an entry named adept.application. This entry includes the name and group that can run this application. adept.application=/BookingsAdept,BookingsAdept.
4. Trees: have 4 attributes - displayFor, hideFor, openFor, lockFor. The first two allow a branch to be hidden or displayed. The latter two specify whether the branch can be opened if it has sub-elements.
5. Input: have 4 attributes - displayFor, hideFor, editFor, lockFor. The first two allow a branch to be hidden or displayed. The latter two define whether the branch can be edited or only displayed as read-only.

--
Posted By Paul Marrington to Adept Development System at 9/03/2007 01:21:00 PM