I want to use SpringSecurity4 in a CDI/EJB environment.
Is this possible? Can SpringSecurity can be used without using Spring?
What I want to do, is to use SpringSecurity with my EJB and CDI components.
Spring Security is basically a filter machine, filtering all the incoming requests. However, plenty of it's functionality is Spring-core dependent. It is possible to utilize Spring in a CDI application, but Spring's core is heavyweight and it's functionality is funny compared to CDI. That would be a downgrade and there would be no point in using CDI.
What you can do is to have a look at some Security projects for JEE world.
Apache DeltaSpike and it's Security module.
Keycloak - The absolute solution. Keycloak goes far, far beyond Spring security's functionality. It is an evolution of old PicketLink libraries developed by JBoss, but those are discontinued and merged into Keycloak instead. An example how simple usage of Keycloak is can be found here.
It is also not that hard to write own security interceptor using #WebFilter and #Inject :), there are several projects on GitHub:
https://github.com/rmpestano/security-interceptor
https://github.com/clairton/security
https://github.com/Rudin-Informatik/cdi-security
https://github.com/rafaelodon/my-security-context
I have no experience with these projects. However, I am always amazed how easily can Spring Security be replaced :)
I am using Spring Security with CDI but I can say it is not very healthy since Spring Security is based on spring and spring is messing with the CDI beans.
Here is what happened to me. I customized the AuthenticationProvider of spring security in order to authenticate users through my authentication server. When implementing this mechanism I used my predefined CDI beans by injecting them using (#Inject) annotation. At this point spring somehow intercepts the injection and creates its own bean, which means you cannot use any of the values you set to the CDI bean previously.
In order to solve this, I did some trick like this:
#Inject
private LoginController loginController;
public Authentication authenticate(Authentication authentication) throws AuthenticationException {
//Here, the injected bean is empty, I am requesting my old bean from CDI and assign it back.
LoginController bm = (LoginController) CDI.current().select(LoginController.class).get();
loginController = bm;
I don't know if this is the answer you are looking for but i hope this helps...
Related
In spring boot, application.yml takes in the Spring oauth2 client config. How do I configure it for the non-boot application. By configuration I mean giving client ID, secret, scopes and redirect URI.
You could find an example here:
https://www.baeldung.com/spring-security-5-oauth2-login#non-boot
You need to:
Build your ClientRegistration.
A ClientRegistrationRepository.
Register your repository on WebSecurityConfigurerAdapter.
If you don't use SpringBoot : there is no application.yml and even if you can add the support of yml files. It won't handle your oauth2 client config.
Anyway you can use Spring security to implement your custom Authorization Service, a User service and implement a Token Store of your choice (JBDCTokenStore or JWTTokenStore for example). But It's a very wide question depending on your business logic.
You can find some well documented samples on :
https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-oauth2
Of course you can handle both XML and javaConfig even mixed Spring confugurations.
Create a #Configuration class with a #ComponentScan on the packages containing components or bean definitions.
#Configuration
#ComponentScan({ "com.firm.product.config.xml","com.firm.product.config.java" })
public class SpringConfig {
}
You can also set properties with #PropertySource() ans #Value annotations. It's very well documented.
This question already has answers here:
Why is my Spring #Autowired field null?
(21 answers)
Closed 7 years ago.
In order to provide POJOs in my legacy web app (Tomcat 8.0.26) with the ability to send ActiveMQ messages I've taken the recommendation to introduce Camel (2.15.2) / Spring (4.2.1) into the app to purely for the purpose of managing pooled MQ connections. I'm hoping there isn't an easier way.
Doing things the Spring way I'm thinking everything would need to be based around an MVC architecture with HTTP servlet aware controllers having access to the servlet context and therefore the Spring context in order to inject beanFactory beans into classes annotated with #Controller and #Service (and in fact there must be a Spring #Controller class that enables Spring to inject the #Service class.
However, as I've stated this is legacy code that will not be using the spring web framework.
After much pain it seems that the only way I can get beanFactory beans injected into my POJOs is to go the AspectJ and Weaving route. Before I go down this road can someone tell me that this is currently the best approach (what I've read describing this solution is from 2011 Can't get Spring to inject my dependencies - Spring Newbie) ? Can you point me to documentation and a working example?
Many thanks.
1) aspectj with #Configurable
In your #Configuration annotated class/es
you can add some more annotations
#Configuration
#EnableLoadTimeWeaving(aspectjWeaving = EnableLoadTimeWeaving.AspectJWeaving.ENABLED)
#EnableSpringConfigured
#EnableAspectJAutoProxy
to enable aspectj and the #Configurable annotation,
you need to import the aspectj lib to your project and add the spring tomcat instrumentable java agent in your tomcat lib folder (give a look here, it exaplains how to configure tomcat) http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/instrument/classloading/tomcat/TomcatInstrumentableClassLoader.html
this is not going to help you if you are going to create your pojos using "new"
MyPojo p = new MyPojo(); // no black magic for this, you will need to satisfies the dependencies yourself) but that would be helpful for example when you load some entities through a framework like hibernate and you want to inject something into them.. #Configurable it's an option that can be evaluated in those cases, for what you describe I would rather not use it.
2) You can have some static methods that uses some static set spring-beans and use them from your pojos, something like
class Util{
private static SprintBeanWithJmsSupport x;
public static setSpringBeanToHandleJmsMessages(SprintBeanWithJmsSupport x){
Util.x = x;
}
public static sendJmsMessage(JmsMessage m){
x.sendMessage(m)
}
}
and you can go with Util.sendJmsMessage(...)
this is a bit shitty but it does the work, I don't personally like this approach
3) set your spring beans in your pojo when they need to use them (maybe behind some nice interfaces that suit your domain)
if you go with spring mvc you will likely end up having some controllers that will use some services (generally they handle security / db access and are the entry point to start the "use cases"), as everything wthin these layers is handled by spring it will be very simple to pass the spring-bean to handle jms messaging to your pojos, this seems to me quite a nice way to handle the problem
I went mostly based on memory and something may not be completely accurate, plus my english is .. what it is, so hope this can be helpful anyway.
Definitely need some expert help with this! I think this is mainly a Spring Security question, but as I don't know for sure, so I am also tagging with the general Spring tag!
When the Application Context is loaded (mine is all via Java Config, though I don't believe that matters), the "DefaultListableBeanFactory" is processed and eventually (via the ProxyFactory) Spring Security Advisors are added. This is great when I have Spring Beans as I have Permissions that need authorization.
My question is: how do I get the same effect when I no longer require those classes to be Spring Beans? Said differently, if I have an object instance created as a singleton bean via Java Config and the authorization is working correctly, is it possible to maintain that with the object instance being a POJO? Again, for the experts, I want the interception chain returned in the JdkDynamicAopProxy to contain the Spring Security interceptors.
And "no", I am not really expecting an answer to this, maybe just hoping!!!
To add security interceptors to beans not instantiated by spring container
switch global-security tag to mode aspectj and weave the provided AnnotationSecurityAspect in the aspecj module.
For your second question I suppose that you want to do one of the following:
Use a ProxyFactoryBean to secure a bean.
Create security proxies programmatically: Use ProxyFactory.addAdvice() method.
Add the security interceptor to all proxies created by an AutoProxyCreator: This usually don't needed, but you can use the AbstractAutoProxyCreator.interceptorNames property to add common interceptors. The global-security tag parser uses a generated name for the MethodSecurityInterceptor, so you need to configure the interceptor manually and set a consistent SecurityMetadataSource.
I would like to achieve this idealism :
To have only 1 implementation for the JSF Bean container, like to use only Spring or Weld but not both. Currently i am using Spring for my backend, so i prefer Spring.
To have only 1 annotation, to choose between #ManagedBean, #Named, #Model
To be able to use all supported scopes, like #RequestScoped, #SessionScoped, #ViewScoped, #FlashScoped, maybe also #ConversationScoped
The JSF Beans could be injected with spring-managed-services (The backend services), perhaps using #Inject or #Autowired
So far i've been finding no best combination to achieve these because as far as i know, please correct me if i am wrong, :
#ManagedBean can not be injected with spring services ?
#Named can be injected with spring services using #Inject, but #Named is using Weld. Can i just use spring to managed the #Named instead of Weld ?
#Named doesnt support #ViewScoped and FlashScope ?
Please share your thoughts and experiences.
Thank you :-)
UPDATE 15 March 2011
Found an interesting page that describes how to replace Jboss Weld with Spring as the JSR 299 CDI implementation. So basically, the question number 2 is answered. Number 1 is also answered indirectly since i can now inject spring services.
But still, the number 3 question remains. I would find very helpful if i can use the #ViewScoped and Flash Scope in the #Named, something like this article. Flash scope implementation has yet to be seen, but the closest one i can get so far is this page.
Hopefully, replacing weld with spring as the jsr 299 implementation will still enable me to use #ConversationScoped.
Gotta test things now, wish me luck :-)
UPDATE 18 MARCH 2011
Successfully make use of Spring 3 instead of weld to do the #Named, #Inject. The important thing is to set the el-resolver in the faces-config.xml.
AFAIK, Spring 3 currently doesnt support CDI yet, so bye2 #ConversationScoped.
For the scoping, i must still use #Scope("request") or #Scope("session"), but if i prefer the #RequestScoped (javax.enterprise.context.RequestScoped) and #SessionScoped, i can make use of the bridge provided from this article.
The Scope("view") for spring from this article works like magic :-)
One problem remain though, how to pass objects between Scope("view")-beans ..
Wish me luck !
update
Ahhh .. finally done ..
Passing the variables using Flash provided by JSF2 really works like magic.
I dont need an 3rd party implementation for that.
So basically, i can do without weld, but with spring, with the common scopes available, including the view scope, dan can pass between beans using the flash object.
One thing missing is the conversation scope, which isnt a major problem to me yet.
Hopefully the future spring can support this conversation scope.
Cheers :-)
I can successfully Inject Spring bean using ManagedProperty annotation like below. This is on JSF Managed Bean. Spring bean is for backend and I prefer spring for backend.
#ManagedProperty(name="userRepository", value="#{userRepository}")
private UserRepository userRepository;
//Setter and/or Getter
value is the most important thing here. It's actually the bean name of spring. I hope this helps.
Weld (actually, the reference implementation of JSR-299 Context and Dependency Injection, also known as Java EE 6 CDI) was less or more invented to supplant Spring in Java EE 6 environments. I would suggest to use Java EE 6 CDI instead of Spring. Why would you use a 3rd party framework when Java EE 6 provides the same functionality out the box?
If the Spring backend really cannot be changed, then I'd suggest to stick to it and not to intermix with Java EE 6 CDI annotations to save yourself from confusions and maintenance headache.
I know this sounds strange, mixing CDI (Weld) and Spring for the controller.
But imagine this situation :
With CDI, i can make use of the #ConversationScoped, which is one of my requirement (And so far i dont know whether i can use spring for this kind of scope, because if i can, i could just replace Weld with Spring, with the el-resolver in faces-config.xml)
My services objects(#Service) along with the DAOs(#Repository) are to be managed by Spring
Now one question arise is that, inside my controller, how can i access my service object ?
Something like this wouldnt work i think :
#Named
#ConversationScoped
public class MyBean {
#Named
private SomeOtherBeanManagedByCDI myOtherBean; // this will work
#Autowired
private MySpringBean mySpringBean; // dont think that this will work
....
}
Any ideas on how to make use of spring beans inside a cdi bean ? Thank you !
update
I've just tested the solution from this article, and so far it works fine, and i feel relieved.
Thank you !
Rick Hightower wrote a nice Extension library which supports to inject Spring beans into CDI beans and vice versa:
http://rick-hightower.blogspot.com/2011/04/cdi-and-spring-living-in-harmony.html
There is still a good accepted answer and some good edits in the OP, but I think there still is time to point out the Seam Spring module.
Also, if you're trying to manage state across a series of pages, and want the effective of conversation management for Struts or JSF or Spring MVC, Spring Web Flow provides just what you need, complete with flow-scoped beans that live for the duration of a flow, more or less equivalent to a conversation in Seam / CDI. If you want a more long lived flow managment solution, the Activiti SPring module makes it dead simple to configure some beans that live for the duration of the process scope, akin to the functionality that Seam had for jBPM.