Recently someone had asked me about security and LWF/WPF generated widgets, so while the thought was still fresh in my mind I figured I'd post what I told them here, for others to benefit from.
Except when WPF generates portlets, which are deployed to production servers as "portlet" WARs and thus protected by the Portal's Authentication/Authorization checks for portal pages and portlets, both WPF and LWF generate J2EE WARs for standalone web application running and Widget use. When accessing a WPF/LWF standalone webapp and/or Widget, you're running it through the LWF/WPF servlet based controller ( /webengine ). Since this is a J2EE WAR, the best way to add explicit security, is to use J2EE Servlet descriptor based security-constraint objects in the deployment descriptor ( web.xml ) to protect access to any resources in the WAR that might be hit directly from the browser.
Many mashups deployments may be internal unprotected news and related non-sensitive data and thus don't care about adding extra protection, but for LWF Widget WARs that contain any sensitive data / actions, you should consider adding security constraints to ensure that malicious users don't try to get at the WAR's resources outside of the mashups authenticated environment. Unlike Portal and Portlets where portlet requests go through the portal, once you have the iwidget definition from mashups (and/or you happen to know the URL), the browser may directly access the WAR hosting the widget(s) - it's not going "through" the mashup server like portlet requests go "through" the portal (and its protection mechanisms) to get to portlets.
There's some more info in the LWF and WPF documentation on security constraints, but basically they're the standard j2ee/servlet defined security constraint mechanism so any j2ee/servlet based documentation on the subject (including but not limited to WebSphere Application Server's documentation on mapping groups to roles etc), would be useful resources.
I hope this info helps,
This topic has been locked.