Spring Boot and Spring Security SAML about spring-security-saml2-okta

[rwinch]

@ulisesbocchio Thanks for bringing this to my attention! We are actually working on an official DSL at https://github.com/spring-projects/spring-security-saml-dsl

I'd love to get your input and contributions!

NOTE: One thing I think we should avoid with the DSL is a base class that is extended as apposed to using the WebSecurityConfigurerAdapter. Requiring a base class to ease configuration makes it difficult to work with multiple extensions (i.e. OAuth and SAML for example).

[ulisesbocchio]

Thanks for your response, I saw the sample project with the DSL, looks real nice, and I get your point about the multiple adapter classes. The question is, wouldn't applying different configurers (saml and oauth2 for instance) in the same WebSecurityConfigurerAdapter could potentially cause issues if the different configurers applied aren't compatible? My understanding is that each WebSecurityConfigurerAdapter creates a separate filter chain proxy, so mixing different configurations in the same WebSecurityConfigurerAdapter would put all the filters in one filter chain, right? I just wonder how they would play together and if there could be any way to isolate the configuration to specific URIs. Something among this lines:

http
    .authorizeRequests()
        .antMatchers("/saml/**")
            .apply(saml())
                ... //saml config
            .permitAll()
        .antMatchers("/oauth/**")
            .apply(oauth())
                ... //oauth2 config
            .permitAll()
        .anyRequest().authenticated()

Basically applying the saml and oauth2 config to specific patterns where the configuration/filters could be isolated (maybe through a sub filter chain) and as far as any of those configurations generate a valid Authentication it should be fine.

[rwinch]

They can coexists perfectly fine assuming they are created properly.

In most instances if you have a different URL processing authentication, then the rest of the application will remain the same aside from a few places (i.e. handle authentication failure, handle unauthenticated requests, etc).

Done properly, things like handling authentication failure can work just fine. You can take formLogin and httpBasic as an example. If both are enabled, by default we perform content negotiation to determine if a 3xx or a 4xx is sent to an unauthenticated user.

If this isn't convincing enough, you can consider a technology like AngularJS and OAuth trying to work together. If they both are using inheritance for configuration, it isn't going to work well. However, a composite style will allow AngularJS configurer to work with SAML, OAuth, etc without any extra work.

[ulisesbocchio]

Yeah, I got you, I guess it boils down to properly creating the configurers/filters to coexist with other things. Thanks for advice!