Portal Systems

Portal systems are a somewhat slippery concept - everyone has a slightly different idea of what they should include. Perhaps, by way of example, we can include content management, document management, course management, scheduling, and messaging (whether via discussion boards, chat, e-mail, etc.). This list is not complete, by any means.

Another definition would get more to the basic nature of a portal: a system that provides a single point of access to numerous different data resources and applications. In this sense, a portal is a glue system that takes more and less related information sources and ties them together into a coherent whole.

Common to the idea of all portal systems is single sign-on: supplying one set of authentication credentials (username and password) and thereby having access to all the components of the portal system. Rather than having several different usernames and passwords, or even just several different places where one must enter the same username and password, the portal asks for authentication just once and then passes this authentication to the other component systems on your behalf.

• PortalComponents: possible subsystems that could be integrated into a portal system.

-- RowanLittell - 04 Mar 2003

So, if Earlham bought into a commercial or Open Source portal system how would the authentication system work? Would we have to use Kerberos if we went commercial and how would a portal integrate with Webdb? Also, How would we transition to a portal? I guess I'm interested in a layman's nuts-and-bolts answer. How would tools like Blog and Twiki fit in??

-- MarkPearson - 05 Mar 2003

Forget Kerberos, for the moment. Kerberos is a protocol designed for authentication in a secure manner. There are plenty such protocols. Kerberos stands out among them as being uniquely difficult to manage and integrate unless you can have complete control over the computing environment of every single networked device on campus. It buys you nothing for off-campus access (whether via web, e-mail, etc.), but creates the expense of managing a complex (if intellectually elegant) authentication structure. It really only starts paying off when you've got an institution an order of magnitude larger than Earlham.

Instead, we will use LDAP. Not much really needs to be said about LDAP, other than it's the same protocol that Windows Active Directory, Apple Open Directory, and Novell eDirectory all use. It's the authentication and user management system that nearly all forthcoming products expect to use. It has the advantages of relative simplicity and extreme extensibility (you can store anything in an LDAP directory).

From the simple user perspective, very little will change about the authentication process: prompt for username and password, and either succeed or fail. From the portal perspective, it simply does this up front when you connect to the portal system. The portal system can then create internally cached representations of those authentication credentials (most portal systems do this differently) to pass off to channels within the portal, whether they be course management, e-mail, blogs, etc.

In the specific cases of TWiki and MovableType, we would probably have to do some modifications to the source code of the programs to accept the cached credentials of the portal. This would probably also be the case in trying to integrate WebDB^? and SquirrelMail^? (which I believe we would want to do). Some of these would be easier than others, no doubt, and as such, they'd come at different points in building the portal - one service would be integrated, followed by others as we could make the necessary changes and write the channel glue code.

On the back end, using LDAP for authentication won't change anything about the user experience, but will mean migrating all the information (once) from its current sources to the LDAP directory. Following this, we will simply reorient the current authentication hooks to point to LDAP rather than their current locations (the great thing about modern operating systems is that they do, to a very large extent, support a plug-in architecture for authentication sources; from the user's perspective it's transparent, and from the administrator's perspective it's as easy as changing a few lines in some configuration files). Skylar and I have already done quite bit of exploratory work into exactly how we could load current authentication information into LDAP and how to make it seamlessly replace current authentication. Once we get all the pieces in place (late spring to mid-summer), it should be a quite and easy process that only will require us to touch a few of the servers and none of the desktops around campus.

Does this answer your questions, or just confuse you further?

-- RowanLittell - 07 Mar 2003

No, it's clear as mud. -- MarkPearson - 01 Jul 2003
to top