We
are working on a modernization program, as part of which we have built a new
enterprise Portal that replaces existing Websphere Portal. This new Portal is a
simple Web20 application with ExtJS4.0/Spring/Restful services running on the VMware Tc Server.
This migration required replacing Webspere Portal components with light-weight open
source products. However, WebSEAL was one product that was impressively lightweight and helped us solve some complex integration problems.
WebSEAL is the resource manager that acts as a reverse Web
proxy. It receives HTTP/HTTPS requests from a Web browser and delivering content from its own Web
server or from junctioned back-end Web
application servers. Web Requests passing through WebSEAL are authorized by the Tivoli Access
Manager.
We were already using WebSEAL for authentication, single sign-on and
high level HTTP URL authorization. In new Portal, we extended its use for
integrating third party application with Portal.
Websphere
Portal (WSP) used WebClipper technology
to integrate and render third-party applications. WebClipper runs from
within the portal server and manage session and identity across Portal and
third-party apps. This solution was highly complex and created tight-coupling
between app and the Portal.
In the
new Portal we replaced WebClipper with WebSEAL-based integration, where we created a
WebSEAL junction for the application, and used the secured junction URL to be rendered
the app as ExtJS Tabs within the Portal. WebSEAL
provided secure
rendering and session management for the app & Portal. WebSEAL also
passed authentication token to the app, as trust HTTP Headers, eliminating the
need to engage Portal server.
We even used WebSEAL as an operational tool to control user traffic at run time. We plan to use WebSEAL to display error pages or redirect traffic to a specific web resources. While this can be done on any webserver, WebSEAL allows the redirection based on fine grain permissions/ACLs.
WebSEAL is an excellent
product, I am not sure if there is any open source product that can provide the
same capabilities. Its only limitation is that it is tightly coupled with
Tivoli Access management and enforces security policies against just Tivoli
Access Manager, also that it is not open source.
Spring Security does provide similar web security against any policy manager and can be configured as an HTTP reserve proxy. However, Spring Security protects web resources within its own web context and needs an application server. If you need to protect third-party web resources/application using Spring security, you will need to stream the HTTP request and attach security headers to it. For protecting simple webservices this approach will work. But for protecting web applications, streaming can create complexities. Moreover, you will need to serve application’s static content through the app server.
As the trend of HTTP interface grows, products provide HTTP/JSON interfaces, ex Solr, CoucbBase , so will the need to non-instrusively secure web-resources . I would like to know how others are solving this problem.
No comments:
Post a Comment