IntegratingAigaion/ExternalLogin/GlobalDesign
From AigaionWiki
< IntegratingAigaion | ExternalLogin
Contents |
Integrated login: Global Design
Introduction
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 here in order to highlight the range of options that are present in the extended login modules of Aigaion.
Login Integration Case Scenarios
[DR 2008.08.17]: I tried to keep the case descriptions simple and understandable. A more extensive discussion of some of the consequences for the design of the login integration modules can be found later.
Case I
Aigaion is used in a research department, to share literature one has read and opinions and notes on the literature. The ICT support desk has made a PHP library available through which on can authenticate using the username and password of one's work identity. Aigaion has been configured to use this library to verify usernames, rather than the built-in module.
Aigaion's configuration has been set to the following options:
- one can only log in with the university ID and password
- public access should still be possible without logging in
- to the user, all login and logout forms and links look exactly the same as when Aigaion had been configured to use its basic login module
- new users, added to the university's list of accounts, are automatically given an Aigaion account as soon as they try to log in to Aigaion for the first time and Aigaion finds that their password is correct but they do not yet have an Aigaion account. This happens because the administrator explicitly enabled the "Create missing users:" option in Aigaion.
Case II
A large project uses an CMS for internal communication. They use Aigaion for internal as well as external sharing of publication info and have extended the CMS system to be able to embed links to Aiagaion entries as well as complete summaries of publications within the pages of the CMS. The CMS is project-internal: minutes, discussions, etc. The Aigaion database contains both internal and public documents from the project. The CMS content pages may refer to documents in Aigaion using a link or an embedded view.
Aigaion's configuration has been set to the following options:
- when a user is logged in in the CMS, he should not have to log in in Aigaion separately, too. When someone is logged into the CMS, reading a document that contains a reference to a project-internal document in Aigaion, one should be able to simply follow the reference and get at the Aigaion entry without going through additional login steps.
- It should be possible to create accounts in Aigaion that are NOT mirrored by an account in the CMS, for people whom you want to give access to some of the non-public documents in Aigaion (e.g. project deliverables), but who should not be able to read or edit the CMS stuff.
- The user should be allowed to log in in Aigaion without logging in in the CMS as well, while using his CMS username/pwd
[DR 2008.08.17]: You know, I have a feeling that some fake screenshots would really help here!
Case III
Aigaion is installed as part of a larger web-based portal which demands high security and into which one logs in only once per session using a very fancy thumbprint verification. This login gives access to a host of web applications that are integrated into the portal, among which Aigaion. If the thumbprint verification has not taken place a user can never be considered logged in in Aigaion. On the other hand, if you are logged in into the portal, you should 'exist' for Aigaion: even if no account existed for you yet in Aigaion, it must be created automatically as soon as you try to access Aigaion. The Aigaion login has been set up as a perfect slave to an external login module. There are no login/logout forms and buttons; a user is only logged in when he is also logged in to the external module.
- no forms, no logout links, all login and logout *controllers* are disabled
- every page access should check the external module whether the user is still logged in in the portal!
Final Case
In this final case, integration goes even one step further. A systems developer wants not only to integrate the login mechanisms of Aigaion and another web based application, but he actually wants to be able to access all session info of one application from the other and vice versa. This requires not only a kind of shared login system, but even the sharing of one session. Note that this is not trivial: by default, Aigaion insists on using its own named session, which will probably clash with the session built in in the other application. This type of integration requires a bit more hacking and coding, and will be discussed at another place. See also the discussion with boldewyn on the forum