myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cagatay Civici (JIRA)" <>
Subject [jira] Commented: (MYFACES-2009) Spring Security integration inside JSF Components
Date Fri, 17 Oct 2008 10:57:44 GMT


Cagatay Civici commented on MYFACES-2009:

I am using Spring Security, Spring based JSF backing beans and MyFaces SecurityContext without
a problem, I use DelegatingVariableResolver.  This combination works, maybe there is an issue
with your configuration. You may use this blog entry based on JSF-Spring-Spring Security-Orchestra-JPA

> Spring Security integration inside JSF Components
> -------------------------------------------------
>                 Key: MYFACES-2009
>                 URL:
>             Project: MyFaces Core
>          Issue Type: New Feature
>          Components: General
>    Affects Versions: 1.1.6
>            Reporter: Juan Pablo Santos Rodríguez
> As noted many times, there is no native integration of Spring Security tags inside a
JSF webapp. I've seen a few approaches, but they're mostly custom JSF-Spring-Security components.
In our current project we needed to use Spring Security tags functionality inside any JSF
component (custom or not). We ended reaching MyFaces' own Security Context (,
which default implementation is J2EE based.
> We've extended it with a custom Spring Security implementation, hence this development,
which is now publicly available, as we think it may be useful for the community. The basic
idea is that Spring's Security Context is going to be available via EL, i.e. you can:
> <h:outputText rendered="#{securityContext.ifAllGranted['ROLE_ADMIN,ROLE_USER']}">how
how how</h:outputText>
> Some notes:
> - The zip is bundled as a maven 2 project, so 'mvn clean install' and add the jar as
a dependency
> - It is a Java 5, Spring 2.5.5, Spring Security 2.0.3, MyFaces 1.1.6 project, this were
customer requirements. Although, all of these should be easily changed, only messing with
dependencies is required O:-) (it should *should* not affect the build, but we've not checked).
> - As it is MyFaces 1.1.x based, it extends Spring's DelegatingVariableResolver. Same
as former statement, it *could* be easily changed, only changing the extended class and the
usual dependency changes. Again, we've not checked (but hey, should be an *easy* change O:-)).

> - Default behaviour of the new Resolver is to check if the requested operation corresponds
to a security operation, if not, runs parent behaviour.
> - IMPORTANT: the security operations available via EL are noted in here:
. Anyone willing to make available any other operation via EL should extend his own
implementation and change his faces-config accordingly.
> - There are several classes which have been taken from tomahawk's 1.1.6 sandbox, in order
to make dependencies management a bit easier. This is noted at class-javadoc level.
> - In jsf-example-webapp module just 'mvn jetty:run' to run the example webapp. There
is a dummy security applicationContext, with users and passwords hardcoded in it (this is
only a dumb demo) inside resources folder. Serious applications will likely have a more complex
> Configuration:
> 1st.- Make your JSF application Spring Security Aware (
> 2nd.- Make your JSF application Spring aware (
This implementation assumes JSF 1.1 integration (
JSF 1.2 will require code modification, as noted above.
> 3nd.- In your faces-config.xml set:
>   <faces-config>
>     <application>
>       <variable-resolver></variable-resolver>
>       <property-resolver></property-resolver>
>       <!-- ... -->
> and that's all.
> cheers,
> juan pablo

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message