This document briefly describes challenges in integrating the three portal products under consideration into our existing web infrastructure. I'll also touch on some of the security concerns the products themselves bring up.
There are several goals we have (or should have?) for any portal product:
The portal has a fundamental assumption that it will get the user's name and password so that it can proxy authenticate to backend servers. This poses a problem for integrating Pubcookie. It's likely that we would have to set fake passwords in the Campus Pipeline directory, and teach the portal to accept Pubcookie authentication from the client and then use the fake password for backend services.
No programming documentation seems to be available, and the standard hooks would probably be insufficient for integration with Pubcookie, so we would either have to engage their consulting services or do some sort of mutual development deal. Campus Pipeline seems to be very receptive to either.
The Campus Pipeline portal general makes connections with the user's authentication to its backend services, such as the LDAP server. In general this is a good thing and how we want middleware boxes to be constructed. Unfortunately, the portal currently authenticates these backend connections using the user's name and password, which was culled at login.
This complicates Pubcookie integration (see above) since the portal will no longer have access to the username. However, this philosophy is the right idea, as security auditing gets considerably simplier. (Verifying that the backend servers function properly gives a much higher assurance.)
I saw no obvious documentation of self-registration facilities.
Not discussed.
Not discussed. If WSRP is supported, similiar concerns apply here as to Epicentric below.
It may be possible to cause the Identity Server to recognize Pubcookie cookies using only the documented APIs in the Identity Server. I would recommend that this work be done to Identity Server 6, since future portal servers will use the latest Identity Server. (Our test portal uses Identity Server 5.1.)
Another possibility would be to implement a Pubcookie module for the SunONE web server, and then have the Identity Server leverage (what it thinks is) HTTP basic auth. Unfortunately, it does not appear that the Identity server comes with an authentication module for basic auth.
Another possibility may be to have the Pubcookie login server contact the Identity Server on user login, and set an appropriate cookie at that time.
Finally, Dave Pickens indicated that Sun was interested in extending the Identity Server so that it would be capable of being a Pubcookie login server. It is unlikely that they have fully considered what this would entail, nor am I sure that it really serves anyone's best interest.
It appears that the network model for the Identity Server is significantly different from how our network functions in practice. The Identity Server's single sign on feature is enabled by a globally scoped (.cmu.edu) cookie, which any application server may read. It appears that possession of this cookie is sufficient for authentication to any application in the domain.
This security is inadequate for CMU's network. This would expose the portal credentials to any other web server in the cmu.edu domain, including dorm web servers or other untrusted servers.
The identity server has built-in facilties for self-registration. (It is called "membership authentication".) I believe certain pieces of the portal can require membership authentication (it would be defined as a seperate "service" in the identity server). It is not completely clear to me how membership authentication and our primary authentication would interact.
Ad-hoc users would be stored in the SunONE directory, in a seperate tree from Andrew users.
Possibly the Identity Server could affiliate a membership authentication with the primary authentication.
Not discussed.
Not discussed.
It does not appear to be possible to integrate Pubcookie using their exposed, documented, APIs, though it is somewhat unclear. The documentation assumes that you want an alternate way of checking username/password, not that you don't want a password at all.
However, the Epicentric portal (as we have it installed) is run under Apache in the Tomcat environment. This makes it especially appealing for Pubcookie integration, since it might be possible to utilize the existing Pubcookie Apache module for the bulk of the work.
Further discussion with Michael Uzquiano indicates that the proper place to look is their SSO classes, and has offered to forward me their existing class for integration with Netegrity.
No current Epicentric customers have expressed concerns about cross-site scripting attacks against the portal, and they don't have any existing security in place against it. However, they do have hooks to run content through on upload, which would be the ideal time to vet content.
It is recommended that a content upload hook that validates HTML safety be developed. We need to balance of the merits of deploying such a client (which will prevent compromises to the portal security) versus a potential desire to use DHTML.
Epicentric has promised WSRP support in a future version. Current versions implement WSUI, an Epicentric prior iteration of the standard. Both of these show tremendous promise for arbitrary end-users to deploy portal services, as they allow simple, verifiable interface elements to be uploaded to the portal while the backend services reside on other machines (presumably one controlled by that end-user). Security policies can be placed on what information a web service is allowed to receive from the portal, though how these security policies are managed or enforced isn't entirely clear to me.
Epicentric could also support uploading arbitrary Java applications (so called "portlets") into the portal framework by users. These applications would run in the same JVM and could degrade overall portal performance (and possibly security) in a hard-to-determine manner. It is recommended that end users not be allowed to deploy such applications and that, whenever possible, all applications should be deployed in the WSRP manner. This will allow easier debugging and monitoring of applications.
It is believed that JSR 168 has similiar security benefits to WSRP. I am not fluent in either specification.
The Epicentric portal has a concept of "realms". It is not clear if the Epicentric realm can be mapped one-to-one to a CMU realm (andrew.cmu.edu or cs.cmu.edu) or if that sort of mapping is even desirable. It appears that making an Epicentric realm that allows self-registration is completely straightforward.