Single Point of Entry
As we have seen, a portal framework aggregates multiple applications in a transparent way, several of those applications (if not all) will likely need a registered user to delivered a customized content.
Flexible portal frameworks will be able to adapt to any authentication method choice, while most portal will use a username and password combination, a bank will probably add a one-time-password token to it or require to have a certificate installed on the user's machine. In any case once that authentication done on the portal, the user will usually never be prompt again for the lifetime of his session even though he will transparently use several web applications during his visit.
Personalization of the portal is a major feature of a portal framework. The portlet specification offers an API in order to adapt the content of a page based on the preferences of the user. A portlet developer could also adapt content based on the user profile or information given by the portal such as the preferred locale for the user (which could be computed from the user's browser preferences).
Some part of the portals may also be restricted to some users.
The portlet specification comes with an API to define user preferences, it is up to the portal framework to store those preferences. An RSS feed portlet will probably let the user define how many feeds the user want to see while the administrator will want to be able to adjust the default value for such a preference.
At the portal level, a theme engine could let the user set the theme of his choice also based on the user preferred language display content accordingly.
Sometimes a portal may also allow users to have a personal dashboard which is a place where the user can create his own pages and compose them with components of his choice.
From the administrators point of view, they may want to restrict pages or windows to certain users or group of users, most portal framework will come with a way to restrict access wither through an API and/or GUI. It also enables to provide a personalized view depending on the user (Such as showing some customer information to a salesperson, instead of a product catalog for a customer).
To conclude, a portal framework exists to solve personalization, and aggregation issues so that developers don't have to reinvent the wheel. Those issues are common to all portals that want to integrate in an existing infrastructure, which have several applications to aggregate or want to provide a personalized experience to the visitor. Differences between portal frameworks comes to their ability to work in a cluster environment for fail-over and scalability, support for web frameworks but also on how they can adapt to the architect and infrastructure requirements.
JBoss Portal Lead