Spring Security integration inside JSF Components
-------------------------------------------------
Key: MYFACES-2009
URL: https://issues.apache.org/jira/browse/MYFACES-2009
Project: MyFaces Core
Issue Type: New Feature
Components: General
Affects Versions: 1.1.6
Reporter: Juan Pablo Santos RodrÃguez
Attachments: myfaces-securitycontext-spring-security-impl.zip
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
(http://wiki.apache.org/myfaces/SecurityContext), 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:
http://wiki.apache.org/myfaces/SecurityContext . Anyone willing to make
available any other operation via EL should extend his own
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/security/SecurityContextPropertyResolver.java?view=markup
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.
Configuration:
1st.- Make your JSF application Spring Security Aware
(http://static.springframework.org/spring-security/site/reference/html/ns-config.html#ns-getting-started)
2nd.- Make your JSF application Spring aware
(http://static.springframework.org/spring/docs/2.5.x/reference/web-integration.html#jsf).
This implementation assumes JSF 1.1 integration
(http://static.springframework.org/spring/docs/2.5.x/reference/web-integration.html#jsf-delegatingvariableresolver).
JSF 1.2 will require code modification, as noted above.
3nd.- In your faces-config.xml set:
<faces-config>
<application>
<variable-resolver>org.apache.myfaces.custom.security.MyFacesSecurityContextSpringDelegatingVariableResolver</variable-resolver>
<property-resolver>org.apache.myfaces.custom.security.SecurityContextPropertyResolver</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.
