Suitability of uPortal for the OSVDB GSoC project
On the suitability of uPortal for the OSVDB Google Summer of Code portal project.
OSVDB's next step towards delivering unbiased security information to the public is to create a customizable portal for members. The portal will allow members to create a custom "dashboard" of security information from public mail lists and RSS feeds, as well as custom views of OSVDB data.
uPortal has excellent flexibility for end-user customization, selecting and arranging widgets into personal layouts. DLM provides a solution for managed fragments that can still be end-user-customizable. While DLM out of the box does not support "pulled fragments", it is feasible to implement this feature via dynamic group membership or custom DLM audience evaluator tricks. uPortal supports RSS feed viewing out of the box, both via the classic RSS feed rendering XSLTs and via Brad Johnson's new more powerful SyndFeedReader channel. Information from the public email lists may also be available via a syndicated feed bridge; if not, Yale and others have implemented uPortal views on IMAP mailboxes which may be a way to implement views on the public email lists in the portal. uPortal supports custom channels and portlets, which would be one option for custom views on OSVDB data, but a better approach might be for the OSVDB product to provide RESTFUL XML views and/or Webservices and have uP channels consume that. The XML approach will work in out of the box uPortal.
The portal will also allow members to store keywords which will generate email alerts when new vulnerabilities are released.
This project can be based on an existing portal framework, such as Joomla, but will require several custom modules to be created and integrated, including:
- integrated mail list reader
- integrated rss reader
- keyword-based alerting service
The keyword-based alerting service would be a custom portal widget, and could be implemented as an IChannel or as a JSR-168 portlet. RSS reading services are available out of the box in uPortal.
A further requirement of the portal is to allow members to be part of groups which can allow access to restricted content. For example, OSVDB volunteers can subscribe to RSS feeds which are otherwise not available to the public.
uPortal excels at providing a powerful groups and permissions API and environment. Permissions can be applied at the within-channel-implementation level (channel as client of uPortal permissions services ala CAnnouncements), at the ability-to-subscribe level. Grouping could also drive pushing privileged fragments to privileged users.
uPortal also works well with CAS, which would be an approach for providing truly secure proxying from the portal to the OSVDB. Non-privileged users would be unable to access the privileged RSS feeds not just because they could not see them in the portal, but because without a proxy ticket the portal would not grant them, they cannot access the raw RSS feeds even if they know their URL. This kind of security architecture might be very attractive to a project focused on security.
PHP is preferred programming language in order to integrate more easily with the OSVDB API. Language may be dependent on the portal framework.
uPortal is Java, not PHP. This is a deficit from the perspective of OSVDB, since their expertise is in PHP. I don't think it has to be an integration barrier, since the best way to architect this is likely the OSVDB system providing XML feeds, etc., and the portal using proxy CAS to proxy to them securely, or just accessing the nonsecured ones, and rendering them. Decoupling portal from OSVDB via an XML layer. Given that kind of architecture, the language of portal implementation becomes less important. To the extent that these are mostly read-only dashboard widgets, XSLT might be a very attractive way to implement them, such that the Java of uPortal is also mostly irrelevant. OSVDB could use uPortal out of the box, skin it, and run with it, continuing to produce the custom code in PHP in their OSVDB product.