IntegratingAigaion/ExternalLogin
From AigaionWiki
Contents |
The Aigaion Login System
The notes in this document have been compiled based on, among other things, many very helpful contributions on the Aigaion forum from boldy, braberli, oyvind, breuera, and many other users.
See e.g.
For discussion, simply add your comment in italics between the paragraphs, prefixed by your initials in square brackets.
THIS DOCUMENTATION IS STILL UNDER CONSTRUCTION. SO ARE ALSO SOME OF THE MECHANISMS DOCUMENTED HERE.
Basic Login Module
The basic login module of Aigaion is a simple design with user accounts with a login name and a password. Each account is also associated with some additional personal information, some user preferences and a list of user rights that determine the access rights of this account (documented elsewhere).
Seen from the user's point of view, the basic login module works as follows: using a login form, the user can login with his Aigaion username and password. The password is checked against the Aigaion internal account table. When login is successful, this info is stored in the session and the user will be logged in as long as the session remains. The user can choose to store his login info in a cookie. If he does that, he will automatically be logged on the next time that he visits the site, without having to go through the login form.
By logging out through the appropriate menu option, the user will be logged out, any login cookies will be removed and the session will be cleared.
Finally, whenever someone is not logged in with his user account, and anonymous guest access has been enabled in Aigaion, the user will be considered to be logged in through one of the anonymous user accounts defined by the database administrator. In that case the menu on the left will show a login form to allow the user to login with a non-anonymous user account that has more user rights than the anonymous account.
Integrated login: Global Design
There are several possible reasons for wanting to modify the Aigaion login module or to integrate it with another system. In the page linked below, a few cases are discussed that should explain a few of the most common reasons as well as show something of the range of options that one needs for the different cases. In summary, one can think of the following situations:
- One might already have a good login account management system, such as IMAP, LDAP, PAM or some already installed other web based system, and prefer to have Aigaion do it's password checking based on the passwords stored in that existing system so that people do not have to maintain two separate passwords.
- One might go a step further, and configure Aigaion in such a way that whenever a user is logged in in another web based system such as a CMS, he will not have to log in separately for Aigaion, but rather will automatically be considered logged in for Aigaion as well.
- The most extreme case may be when a user is to be considered logged in in Aigaion if and only if he is logged in in another system, making the Aigaion login mechanism a complete slave to the other system.
Several cases/scenarios are presented on IntegratingAigaion/ExternalLogin/GlobalDesign in order to highlight the range of options that are present in the extended login modules of Aigaion.
Some More Requirements and Considerations
A number of requirements and nice-to-haves for the login modules of Aigaion are discussed on the following separate page: IntegratingAigaion/ExternalLogin/Requirements. Here you will find, for now, an unsorted collection of remarks and features; in time, these will be sorted into a proper collection of ordered requirements for the login modules.
Detailed Design
Given the Case descriptions from above, and the requirements collected on the requirements page, this section presents the detailed design. The basic model of the Aigaion login modules is as follows. There are three 'modes' in which login can work.
The first is based on only enabling the Aigaion internal login module, possibly with anonymous login facilities.
The second is based on the possibility of delegating the password checking to an external system. One can optionally configure Aigaion to use the internal login modules as fallback for accounts that have been designated as 'Aigaion internal only'; as final fallback, anonymous login may still be possible. This mode covers Case I completely.
The third and final mode of operation is much more complex, and involves not only checking whether a user/password combination is valid in the external system, but more specifically whether a certain user is at this moment logged in the external system from the client computer from which Aigaion is being accessed. Case II involves a combination of features from the second and third mode.
Details can be found on the page IntegratingAigaion/ExternalLogin/DetailedDesign