spring-projects/spring-security

Welcome. Ask away! Unless otherwise specified we assume you're using the latest 6.x version of Spring Security

CH4:D

@chad_d_stud_twitter

what’s the webflux equivalent of this implementation?

public class AuthenticationFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws ServletException, IOException {
}

this won’t work anymore on webflux since it doesn’t have a servlet object

Omid Dehghan

@odchan1_twitter

Hi, Can someone help me here please? I'm newbie to Spring-Security and just for warm-up I decided to do a little example. The problem in the code below is that, when I'm trying to pass the "right username and password" to the login page, it direct me to a page which says access forbidden code 403 .
Here is the code:

@org.springframework.context.annotation.Configuration
@EnableWebSecurity
public class Configuration extends WebSecurityConfigurerAdapter {

    @Override
    public  void configure (AuthenticationManagerBuilder auth) throws Exception {
        PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
        auth.inMemoryAuthentication()
                .withUser("Ian").roles("user").password(encoder.encode("password"))
                .and()
                .withUser("Charlize").password(encoder.encode("password")).roles("admin","user");
    }

    @Override
    public void configure(HttpSecurity http) throws Exception{
        http.authorizeRequests()
                .antMatchers("/dir","/dir/*").access("hasRole('user')")
                .antMatchers("/","/*").permitAll()
                .and().formLogin().loginPage("/login/form").permitAll()
                .loginProcessingUrl("/login")
                .usernameParameter("userParam")
                .passwordParameter("passParam");
    }

}

This is how the form looks like:

<form method="post" action="/login" >
    Username:<br>
    <input type="text" name="userParam" id="userParam" value="Mickey">
    <br>
    Password:<br>
    <input type="password" name="passParam" id="passParam" value="Mouse">
    <br><br>
    <input type="submit" value="Submit">
</form>

Omid Dehghan

@odchan1_twitter

In case anyone was interested in the problem above, the problem was about the way I set the action of the form page.
I'm using thymeleaf and the form-action should be defined like this: th:action="@{/test}"

CH4:D

@chad_d_stud_twitter

Question, does the sequence of the ServerHttpSecurity matter?
I’m trying to convert the following from an existing non-reactive code:

 @Bean
    SecurityWebFilterChain springWebFilterChain(ServerHttpSecurity http) {
        // Spaces show where the old code use to be separated.
        return http
                .csrf()
                .disable()

                .addFilterBefore(new AuthenticationWebFilter(), SecurityWebFiltersOrder.HTTP_BASIC)
                .authorizeExchange()
                .pathMatchers("/v1/**")
                .authenticated()
                .and()

                .exceptionHandling()
                .authenticationEntryPoint(authenticationExceptionHandler)
                .accessDeniedHandler(customAccessDeniedHandler)

                // This used to be part of configure() in SecurityConfiguration()
                .and()
                .authenticationManager(customAuthenticationProvider)

                .cors()
                .and()
                .build();
    }

James Howe

@OrangeDog

Where can I give feedback on this? Raise a github issue?
https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Features-Matrix

Andreas Falk

@andifalk

@OrangeDog what Feedback do you have here?

James Howe

@OrangeDog

Primarily that it appears to have a narrow definition of "opaque token" as implemented in Spring Security of "arbitrary string that you make a web request to the auth server to get the details of" instead of what Spring Security OAuth has also implemented - "arbitrary string that can be looked up via any method, in particular a JDBC, Redis or in-memory database shared with the auth server"

James Howe

@OrangeDog

More generally, it doesn't capture what SSO allows you to customise and extend at a single point, but which SS perhaps doesn't. Going by what I'm using, that's the aforementioned TokenStore, but also the TokenGranter, RequestFactory, RequestValidator, and ConsumerTokenServices.

I've got lots of bits put together so I could build a page to view and revoke the access that you've granted.

James Howe

@OrangeDog

Basically, I'm concerned everything I'm using is going to be left out from the "feature parity"

Andreas Falk

@andifalk

@OrangeDog Spring Security 5 implementation is more strict to what the OAuth 2.0 and OpenID Connect specs define. Regarding opaque tokens, the OAuth 2.0 standard only defines an introspection endpoint (https://tools.ietf.org/html/rfc7662) to validate such a token. Additionally, the OpenID Connect specification defines a user info endpoint (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) to ask for more user details using an access token. All other means like "arbitrary string that can be looked up via any method, in particular, a JDBC, Redis or in-memory database shared with the auth server" are not according to the standard and bear security risks. Especially the database of the auth server should be used exclusively by the auth server and must not be shared with any other party!
In case you want to persist tokens in your OAuth2/OIDC client then you have to implement the interface "OAuth2AuthorizedClientRepository" yourself to store data it into a database (e.g. Redis). The default implementation just stores the data in the HTTP session.

James Howe

@OrangeDog

As I feared. There are no specific standards for other opaque token implementations, because they don't require different systems to talk to each other, so there's no need to define any public communication protocols. It is very common that the auth server and the resource server are the same party, even implemented in the same process.

The core OAuth 2.0 spec says you can implement bearer and authorisation tokens however you please.

I'm not maintaining a client, I'm maintaining a web service that allows other developers to use its api.

Andreas Falk

@andifalk

So what you are implementing is a resource server.

James Howe

@OrangeDog

and an auth server

Andreas Falk

@andifalk

In OAuth2 you have a clear separation of concerns: Auth Server, Client and Resource Server. That is basically the basic idea of OAuth2.

James Howe

@OrangeDog

I know that. And my application as a whole includes both an auth server and a resource server.

And in a minimal deployment, they're the same process.

Just like every web service that both has its own accounts and offers api access

But Spring Security seems to be taking a very narrow view of what OAuth is and completely cutting out this use case, that was amply served by Spring Security OAuth

Andreas Falk

@andifalk

That is what Spring Security OAuth just provided with its "EnableAuthorizationServer"/"EnableResourceServer" annotations. With these, you could implement an AuthServer also providing a user info endpoint (which acted like a resource server). You won't find this with any other OAuth/OIDC provider like Keycloak, Okta etc.

James Howe

@OrangeDog

Obviously not, because those are ID providers. They're not systems like Facebook or Google or Github that have their own accounts and also a developer api.

OAuth is not just an authentication/ID system.

Jeff Beck

@beckje01

Maybe I missed something (its likely I did) is there a move to deprecate the EnableAuthorizationServer path?

James Howe

@OrangeDog

The entirely of Spring Security OAuth is being deprecated this week

Jeff Beck

@beckje01

OK so yes I'm a bit behind

James Howe

@OrangeDog

but Spring Security does not have feature-parity

Stephan R

@mrpubnight_gitlab

Hoping to get a little help about configuring multiple OAuth2 IDPs in our Spring Boot API Gateway. We are currently using Zuul but are also PoCing Spring Cloud Gateway so either is relevant.

We'd like to use tenant URLs for our Federated users each using a different IDP for authentication but ultimately have them go through the same gateway. Is there a way to switch OAuth configurations based on the tenant of the URL? A couple considerations; 1) we do not want a login selector screen - we'd like to manage that through different security configurations, 2) the redirect URL should contain the tenanted URL. Is this possible? Easy/Hard?

James Howe

@OrangeDog

and from what Andreas is saying, it sounds like it never will

Andreas Falk

@andifalk

But for Facebook, Google or Github this just the same. They also separate the OAuth2 token retrieval process from using their APIs with such a token.
Spring Security OAuth has been a bit insecure implementation that is why Spring switched to use Nimbus SDK to do the OAuth2 stuff instead of implementing it themselves.
@OrangeDog If you are looking for a multi-tenant IDP feature, this has been added in Spring Security 5.2 (https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#oauth2resourceserver-multitenancy).

James Howe

@OrangeDog

I can guarantee to you, they do not solely use RFC 7662.

I am simply looking for opaque tokens that are not implemented using RFC 7662

I am not interested in IDP at all - you are exactly proving my point that you have a very narrow view of OAuth. It is not an identity provider protocol!

It is very frustrating, having been involved in the development of OAuth2.0, to see Spring discarding all the deliberate flexibility in a misguided view that if there's no published RFC then it's not a valid method of implementation.

Andreas Falk

@andifalk

Yes, OAuth 2 is an authorization delegation framework, for authentication you need OIDC. But what you want to achieve is not part of the OAuth 2.0 standard as well. Facebook, Google might just have additional features compared to standard OAuth2.

James Howe

@OrangeDog

The OAuth 2.0 standard is not a description of implementation details.

Andreas Falk

@andifalk

Yes that is why OAuth 2.0 is named a framework. But OAuth 2.0 does NOT define any specific token type.

James Howe

@OrangeDog

Exactly

So why are you insisting that the only valid implementation of an opaque token is required to use RFC 7662?

The token may denote an identifier used to retrieve the authorization
information

that's all I want

that's what Spring Security OAuth provides

in contrast, Spring Security lacks even a basic getTokenDetails(String token) interface

Andreas Falk

@andifalk

Yes, this is correct. You may use opaque tokens in any way you want. But if you want to use opaque tokens together with OAuth 2.0 then RFC 7662 clearly defines how to validate such tokens in this case. Spring Security OAuth neglected these standards

James Howe

@OrangeDog

This specification defines a method

a method, not "the exclusively valid MUST use method"

Which should be obvious, because it was written three years after RFC 6749, and five years after RFC 5849

Where communities thrive

People

Repo info

Activity