Ideas on how one might implement an IP-address-based weak authentication mechanism for uPortal.
High Level Discussion
There's a whole lot of public content
There's a great deal of public information available. The Web, for instance, is largely publicly available information. Some amount of this information is suitable for presentation as uPortal channels. One way we customize the public information that individual users receive – one way we provide value in portals – is by allowing the user to authenticate and receive a layout populated with information that she has chosen or someone has chosen for her from the universe of available content, which includes both public content (authentication was for the purpose of identifying her preference to see this particular public content) and private content (authentication was for the purpose not only of identifying her preference to see this particular content but was also for the purpose of authorizing her to see the content.)
We can make meaningful gueses about what public content a user might want to display before she logs in
While there is no substitute for the full power of user authentication to see private content and a truly personalized, end-user-configured, layout, we can nonetheless make some educated guesses about what in the universe of available content we wish to present to a non-authenticated user.
A persistent per-user cookie
Conceivably, uPortal could place a persistent per-user cookie that would inform the guest layout. It might result in the user being "logged in" and those channels that display public information would render – if the user layout itself is not regarded as private information. Alternatively, one might allow the user to configure a custom guest layout consisting only of publicly available channels.
IP address tricks
The user IP address conveys a lot of information. From it, you might be able to determine:
- that a computer was registered to receive an IP address, and by whom it was registered
- whether the computer is an institutional cluster computer, if so what kind and where
- whether the computer is on a residential or administrative subnet
- what institution the computer is at, in the case of a uPortal serving multiple institutions.
- which School within a University the request is likely coming from
Of course, it's inappropriate to use IP address for authentication – there are too many well know IP address spoofs – but it's a plausible way to filter and customize public information.
We might use this IP address information to select an entire layout, or we might use it to inform the content to be displayed by particular channels.
Network Registration
At Yale one year we placed a channel on our guest layout front page that, based on the IP address of the request, would detect the case where the request was likely coming from an unregistered computer on a student subnet and in that case displayed an invitation to "Click here to register your computer!".
Single Sign On
Incidentally, Single Sign On has something to offer here. If a user has only to authenticate once and then her entire web session is authenticated, and if resources she accesses can detect this authenticated state and jump directly to logged in state, then the need to play these non-logged-in guessing games is lessened. Logging in is a good thing. The authenticated experience should be so compelling, so effectively present exactly what the user didn't even realize she was eager to know, that users should be logging in.
On predicating guest content display upon requestor IP address
Suppose we're doing the IP address trick. Here's a plausible implementation story:
Use Case
On the basis of the IP address, we will categorize our users into one of three categories:
User categories |
|---|
Yale user |
Rutgers user |