spring-security-oauth2 vs spring-security-oauth2-core in Spring - spring

What is the difference between spring-security-oauth2 and spring-security-oauth2-core in spring?
Is spring-security-oauth2 substituted by spring-security-oauth2-core?
spring-security-oauth2 release link :
http://repo.spring.io/release/org/springframework/security/oauth/spring-security-oauth2/
spring-security-oauth2-core release link
http://repo.spring.io/release/org/springframework/security/spring-security-oauth2-core/

Yes there is a big difference. spring-security-oauth2 (Spring Security OAuth Project) is no longer being actively developed.
Moving forward, it will be implemented in Spring Security 5 (in spring-security-oauth2-core). It's pretty confusing because many tutorials use the previous Spring Security OAuth (#EnableResourceServer, #EnableAuthorizationServer, and #EnableOAuth2Sso annotations usually give it away).

The first link is related to Spring 4 and it's matching Spring Security versions. You can verify this in the pom.xml files.
The second link is related to Spring 5 and Spring Security 5. Not only is this directly apparent from the version you see mentioned in that link but you can find the dependency directly named in the Spring Security 5 documentation.

The difference is described in the spring git repository
https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
it is the old library: security/oauth/spring-security-oauth2/
As you see, the library is in the 'oauth' group of spring-security.
I don't recommend using the old library as a client because there are many unresolved issues including the issue about the storing of clientContext (the library use proxy instead of the plain entity for that reason you will have issues when you use MA with distributed cache ). Also, it doesn't allow to use several OAuth2.0 providers simultaneously (only one).
At the same time, that library provides a significant advantage, to use Authorization Server that doesn't implement in the new library.

Related

Correct guide about spring Oauth 2

I'm studying in details the use of spring security (not only oauth), so I'm following this official guide: https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle.
This guide have Oauth section and following it I got everything works. But after another research in internet a found a another guide (from pivotal too): https://spring.io/guides/tutorials/spring-boot-oauth2/.
This second guide use others classes that don't exist in first guide, and other way to configure spring Oauth.
I'm very confused what guide should I follow and what is "more correct".
Both guides are correct.
The first guide you mentioned (https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle) uses the newer OAuth 2.0 functionality in the Spring Security project, so it's recommended you use that one.
To give you some background, functionality from the Spring Security OAuth project is being migrated to core Spring Security.
The first guide you mentioned uses core Spring Security, and the second guide uses the Spring Security OAuth project.
For more information on the features available in the various projects, as well as FAQs, you can check out the OAuth 2.0 Features Matrix.

Spring Boot and dependency for spring-security-jwt

I'm migrating a Spring Boot project from boot 1.5.x to 2.0.x.
In the 1.5.x project I see that the following dependency is being used:
dependencies {
...
compile("org.springframework.security:spring-security-jwt")
...
}
The version of the spring-security-jwt is managed by Spring and I can verify that here. Namely:
<spring-security-jwt.version>1.0.9.RELEASE</spring-security-jwt.version>
The same dependency fails to resolve when I move to Boot 2 because it is no longer managed by Spring. I can verify that here...
Is this a bug or it is removed and included in another lib? Somehow I can't find clues in the docs... Shall I manage the version manually now?
The spring-security-jwt (and OAuth as well I guess) are now obsolete. Spring Security 5 added that support to the core library instead of an extension of the framework.
See here for a list of tickets related to the core JWT and OAuth support.
So in short you don't need that dependency anymore, although if you have custom filters and functionality build around that it would require using different classes/packages and features.

Spring Security without spring core?

I have a really simple question, that I just can't find the answer.
If I want to use only Spring Security, do I need Spring core or any other dependency?
In this link, in the bottom I see only spring security jars as dependencies, but still I couldn't get it to work. I only got it to work when I used a lot more of spring jars (core, context, and more).
So, what are the minimal dependencies I need for using Spring Security? All I need is an authorization and authentication framework, and I want as little dependencies as possible.
Thank you!
For every spring extension you need to use Srping core, because every extension is build on top of spring core

Spring security vs Apache Shiro [duplicate]

This question already has answers here:
Shiro vs. SpringSecurity [closed]
(3 answers)
Closed 4 years ago.
What I have researched so far most people are saying Apache Shiro is easy to use and easy to integrate with CAS (for SSO etc). Just to ask if anyone has experience using both of them and which one to use and why one is better than other?
Many of the Shiro developers use Spring for their applications, so Shiro works beautifully in Spring environments. The general feedback we've received thus far is that Shiro is also far easier to understand (for most people) than Spring Security.
If you want full Session clustering support across any web container however, only Shiro will support this easily. Shiro's crypto is also very simple/easy to use.
Choose which fits your mental model best - both will work great in Spring environments.
I have recently had to evaluate both shiro and spring security. We went with spring security (in fact we extended spring security to use the shiro permission strings in a better way - with instance variables on annoations).
Spring Security
under active development.
has much more community support.
Spring security has extensions providing support for both Oauth and kerberos
and SAML.
Shiro
Does not support saml or Oauth.
Makes no mention of supporting before and after security policies.
Active development seems limited, the website still
contains erroneous information.
I have evaluated both Shiro and Spring security. The main advantage that people claim about Shiro is simplicity, but I believe that Spring Security (3.0) is not crazy complicated. It took me almost the same amount of lines of configuration to set up. Also Spring Security is much better documented than Shiro.
But the main issue with Shiro it is that it doesn't support OAuth or Digest Authetication (they are planning to include it in the future https://issues.apache.org/jira/browse/SHIRO-20 ).
My conclusion: Today I would go for spring security.
Shiro is better to use. Its code much simple which provides you flexibility to extend it and provide your custom behaviour wherever needed. It also provides internal cache implementation of Ehcache through which you can replicate session on server clusters.
If you are going to design RBAC(Role based access control) system for your application it will provide you flexibility to handle asset level permission and its access control mechanism is much flexible as compared to spring security.
Spring Security and Shiro both sets awesome with Spring framework. i have tested both of them . for me spring security was easy to integrate and is totally understandable according to developer points of view. and Shiro is also easy to integrate but for me Spring is more easy to integrate.

Spring Framework, Spring Security - possible to use Spring Security without Spring Framework?

Ive been working now with the Spring Framework 3.0.5 and Spring Security 3.0.5 for several time. I know that Spring Framework uses DI and AOP. I also know that Spring Security uses DI, for example when writing custom handlers or filters. Im not sure whether Spring Security also uses AOP - so my first question is: does it?
Well, Id also like to know how Spring Security can be used for non-spring-based applications. Its written in their documentation that this is possible. Well, I wonder how - it seems like it uses DI, so how should it work in a simple java web application? I guess at least a web container which supports dependency injection is needed, correct? (Which one could that be?)
Thank you for answering :-)
[EDIT]
documentation says:
"documentation says: "Spring Security provides comprehensive security services for J2EE-based enterprise software applications. There is a particular emphasis on supporting projects built using The Spring Framework, which is the leading J2EE solution for enterprise software development. If you're not using Spring for developing enterprise applications, we warmly encourage you to take a closer look at it. Some familiarity with Spring - and in particular dependency injection principles - will help you get up to speed with Spring Security more easily.""
j2ee-based enterprise software applications......... emphasis on supporting projects using spring framework...... well this means it should be possible to work with it without Spring Framework itself!
?
AND:
Even though we use Spring to configure Spring Seurity, your application doesn't have to be Spring-based. Many people use Spring Security with web frameworks such as Struts, for example.
This is from the spring security homepage. well....
Does it use AOP ?
Yes spring-security uses AOP for its method security (you'd have to search the page to find it).
Can you use spring-security without spring ?
Generally no.
As you need to define spring beans for several spring-security elements.
But! You can use Acegi security without spring as far as I know. Which should give you close to the same functionality.
Can you secure a non-J2EE application
Definitely.
Anything that can run in a servlet container can be secured with spring-security. You just need Spring's IoC/DI.
This answer can help you on the minimal spring-security dependencies.

Resources