renderedOnUserRole is only reliable when using the ACEGI security. We need to test ACEGI with portlets to see if supporting this API is feasible with ACEGI configured.

Code changes for

http://jira.icefaces.org/browse/ICE-2625

have resolved this for synchronous mode portlets. To resolve for asynchronous mode will either require configuration of acegi for portlets (not sure if this is possible) or, under the conditions that it is possible, to use an alternate portlet request to detect the user role (such as a blocked request).

A separate JIRA will be created for portlet asynchronous security.

Unfortunately, we didn't interact with the portlet correctly during initial testing. User roles are lost during portlet interaction (we believed at the time it was due to Ajax Push) because those interactions take place via ServletRequest objects, not PortletRequest objects.

To support user roles with Portlets we will likely need either: acegi for Portlets, or to cache user role determinations (note that the caching cannot work in all cases because the user roles could change during portlet execution, which is potentially a security hole, and user roles requested during the initial page view may be different from those requested during subsequent views; there are reasonable ways to structure pages to work around this, however).

General and proper portlet support for ICEfaces 2.0 falls under the parent issue of the JSF Portlet Bridge.

This is only relevant to the IF 1.8 compat components in IF 2.0.

The new portlet bridge does support this usage and all the ICEfaces 1.8 components that rely on ExternalContext() isUserInRole method to determine the validity of the user's role are supported. This includes custom attributes like renderedOnUserRole. Going forward, the next generation of ICEfaces components will not expose similar custom attributes but the same functionality can be achieved by using simple EL expressions bound to standard attributes like rendered or disabled.