spring-cloud / spring-cloud-common-security-config Goto Github PK

View Code? Open in Web Editor NEW

19.0 23.0 31.0 336 KB

A common security infrastructure used by Spring Cloud Data Flow and the projects in its ecosystem

Java 98.29% Shell 1.71%

spring-cloud-common-security-config's Introduction

⛔ Spring Cloud Dataflow has moved to a monorepo.

This repo is archived and now exists as the spring-cloud-common-security-config module in the Dataflow monorepo.

Please file any issues/PRs in the Dataflow repo.

spring-cloud-common-security-config's People

Contributors

Stargazers

Watchers

spring-cloud-common-security-config's Issues

Update Spring Security OAuth to 2.3.6

Line up Spring Security dependencies for 2.3 GA

@sabbyanandan commented on Thu Nov 14 2019

Decide how to pull spring-security-oauth2.2.3.7.RELEASE as part of the 2.3 GA release.

This component will be updated in spring-cloud/spring-cloud-common-security-config; eventually, we will bring the aligned security stack in SCDF and Skipper.

Role based access control

Maybe I misunderstood the authorization concept with scopes (as I only know a few of the idPs)

Scope-based access control is giving 3rd party application permission to execute actions on the user's behalf.

But, I consider the SCDF more as an enterprise application, which requires role-based access control.
The user shouldn't be allowed to give consent to these scopes and gain access to an enterprise application.
I guess most companies don't like that.

The permissions should be given by the companies access control.

Also, most company applications are accessible only through a gatekeeper, which is doing the authentication and authorization.
For that setup, only a ResourceServer with a JWT token is required, but the OAuthSecurityConfiguration will fail if there is only a resource server configuration without an OAuth ClientRegistrationRepository.

Did I miss something in the concept? This project is already used 4 years in SCDF.
Is there any company, which is using the scope base authentication?

I assume most companies will override this default OAuthSecurityConfiguration by defining their own security configuration.

I'd be glad to learn more about where and how the scope-based access control is used.

Migrate to junit5

Role mapping with jwt broken

Currently CustomOAuth2OidcUserService gets confused if map-oauth-scopes is set to true. This is because with azure permission name is dataflow.create and exposed api aka scope api://dataflow-server/dataflow.create.

While CustomOAuth2OidcUserService would expect

role-mappings:
  ROLE_CREATE: dataflow.create

And MappingJwtGrantedAuthoritiesConverter expects

role-mappings:
  ROLE_CREATE: api://dataflow-server/dataflow.create

All boils down to as jwt contains dataflow.create in scp field but other parts doing mapping will see api://dataflow-server/dataflow.create.

Don't hit UserInfo UAA endpoint for Client Credential Grants

For Client Credential Grants, we should not hit the UserInfo REST endpoint (As that is an OpenId Connect-specific endpoint). As a temporary solution (until Spring Security 5.2 migration) we should only hit the UserInfo REST endpoint if a the passed AccessToken is of scope openid.

We should also, slightly expand the PrincipalExtractor and search for properties cid and client_id. That way we have an identifiable moniker e.g. for auditing.

DefaultAuthoritiesMapper is parsing scopes as URI having a leading slash

Hey,

currently we have an issue with the mapping of authorities. Our scopes containing information divided with a / sign. Example: /F///FUNC/2000803036///X

Because of the following method:

spring-cloud-common-security-config/spring-cloud-common-security-config-web/src/main/java/org/springframework/cloud/common/security/support/DefaultAuthoritiesMapper.java

Line 216 in bccaa04

private Set<String> pathParts(Set<String> scopes) {

- the scope is parsed as a URI and cropped after the first /.

Because of this we have to define our role / scope mapping like:

    spring:
      cloud:
        dataflow:  
          security:
            authorization:
                user_login:
                  map-oauth-scopes: true
                  role-mappings:
                    ROLE_CREATE: 'F///FUNC/2000803037///X'

As of the RFC https://datatracker.ietf.org/doc/html/rfc6749#section-3.3 scopes are just Strings and should be handled like this, so it might be good to make this functionality of parsing as a URI optional / configurable so that the scopes are not parsed when they shouldn't.

Thanks a lot in advance.

Implement dummy UserDetailsService

As we are opinionated with security. When we go and use IgnoreAllSecurityConfiguration, we should also implement custom no-op UserDetailsService not to create default user.

Validate scope of the OAuth token

When retrieving an OAuth Token from the OAuth server and then use that token against the Spring Cloud Data Flow Server it seems that the scopes are not re-populated.

Update Boot + Spring Security Oauth2 version

This is for the 1.0.x branch only. We need to update the Boot version to 1.5.16.RELEASE

Make Spring Session Repository Configurable

Currently we provide as a default a MapSessionRepository. However, we should also provide an option to support SQL-based session storage:

https://docs.spring.io/spring-session/docs/current/reference/html5/#httpsession-jdbc

Possibly, we should also document on how to enable Redis-based session storage (without having a hard Redis-dependency in the project). Not sure if that would be possible, though.

Handle deprecations

Update spring-security-oauth2 dependency

Define nimbus dependencies

Issue with dataflow 2.6.x where we get due to a bit crazy version management in numbus poms. With dataflow 2.7.x gets good versions from boot 2.3.x but 2.2.x doesn't manage nimbus so we should manage versions here in 1.4.x line and then dataflow/skipper should get correct versions.

Original issue reported spring-cloud/spring-cloud-dataflow#4223

Accept / logic breaks with auth entry points

There is a change in core spring-projects/spring-framework@f399446, which now causes

o.s.s.w.util.matcher.AndRequestMatcher   : Trying to match using NegatedRequestMatcher [requestMatcher=MediaTypeRequestMatcher [contentNegotiationStrategy=org.springframework.web.accept.ContentNegotiationManager@27dc79f7, matchingMediaTypes=[application/json], useEquals=false, ignoredMediaTypes=[*/*]]]
o.s.s.w.u.m.MediaTypeRequestMatcher      : httpRequestMediaTypes=[*/*]

While in core 4.x we got

o.s.s.w.util.matcher.AndRequestMatcher   : Trying to match using NegatedRequestMatcher [requestMatcher=MediaTypeRequestMatcher [contentNegotiationStrategy=org.springframework.web.accept.ContentNegotiationManager@44cb460e, matchingMediaTypes=[application/json], useEquals=false, ignoredMediaTypes=[*/*]]]
o.s.s.w.u.m.MediaTypeRequestMatcher      : httpRequestMediaTypes=[]

We're been using:

.defaultAuthenticationEntryPointFor(new LoginUrlAuthenticationEntryPoint(loginPage), textHtmlMatcher)
.defaultAuthenticationEntryPointFor(basicAuthenticationEntryPoint, AnyRequestMatcher.INSTANCE);

As MediaType.TEXT_HTML always matches with */*, we're always getting redirect to login page, instead of 401 with curl. We need to change this logic how entry point is chosen.

Spring Cloud Data Flow - main method missing

Hi Team,

May I know how can I integrate this 'spring-cloud-common-security-config-web' code in Spring Cloud Data Flow Server. When I tried to launch the program it is showing as that main method is missing.

Thanks,
Anumol

Add core module

Create a core module, so that code can be re-used with having to trigger AutoConfiguration classes.

Don't force basic auth for JS client

When security is enabled and session is invalid, http requests from UI will be given header

www-authenticate: Basic realm="Spring"

We want to use a common X-Requested-With hack to conditionally just return plain 401 to UI by using something like:

.defaultAuthenticationEntryPointFor(
	new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED),
	new RequestHeaderRequestMatcher("X-Requested-With", "XMLHttpRequest"))

Backport commits to 1.1.x

Backport the following commits:

26260e7
d2daa99
eeb5f5c

Support OAuth2/OpenID Connect Only

Remove deprecated spring-security-oauth2

Remove dependencies and test for deprecated spring-security-oauth2.

Upgrade to Spring Boot 2.0

Update Spring Boot version to 2.1.6.RELEASE

Add roles SCHEDULE, DEPLOY, DESTROY, MODIFY

Depended on by spring-cloud/spring-cloud-dataflow#2582

Security configuration which disables security

As boot2 effectively removed all of its tweaks for security auto-configuration, we need to come up with config which effectively disables all security features. As we used to hook into boot1 security.basic.enabled and other settings, we need to come up with a condition which is true if user haven't added any security settings. This condition would then craft a dummy security config which would fake boot not to enable its own WebSecurityConfigurerAdapter which then effectively adds springSecurityFilterChain and @EnableWebSecurity is enabled.

There were a discussion in spring-projects/spring-boot#10306 to make this easier in boot but that ticket didn't go anywhere and I'm not sure any kind of security features would belong into boot anyway. Our use case is highly opinionated and these opinionated use cases were reason boot removed its own tweak in favour of forcing users to do their own configs.

Support jwt with resource server

For a sole support for identity providers which provides jwt tokens.

Upgrade to boot 2.1.x

Make OAuthSecurityConfiguration extensible

Remove token from the TokenStore on logout

Misleading behavior when map-oauth-scopes=true and no roles were matched to the user's scopes

Hello,

I've been trying to configure the latest SCDF to authenticate with UAA.
While authentication seems to work, when using custom authorization using map-oauth-scopes, I ended up getting an exception from CustomPlainOAuth2UserService.loadUser, which attempts to call spring security DefaultOAuth2UserService, stating that "authorities cannot be empty".
To my understanding (and looking at https://docs.cloudfoundry.org/api/uaa/version/74.4.0/index.html#introspect-token), authorities are only applicable for client tokens.

@ghillert Any idea how should this flow work?

Here's additional info:
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT 2020-01-02 15:58:07.345 ERROR 7 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT java.lang.IllegalArgumentException: authorities cannot be empty
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.util.Assert.notEmpty(Assert.java:464)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.security.oauth2.core.user.DefaultOAuth2User.(DefaultOAuth2User.java:63)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.cloud.common.security.support.CustomPlainOAuth2UserService.loadUser(CustomPlainOAuth2UserService.java:54)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.security.oauth2.client.authentication.OAuth2LoginAuthenticationProvider.authenticate(OAuth2LoginAuthenticationProvider.java:116)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:175)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.security.oauth2.client.web.OAuth2LoginAuthenticationFilter.attemptAuthentication(OAuth2LoginAuthenticationFilter.java:185)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:212)
2020-01-02T15:58:07.34+0000 [APP/PROC/WEB/0] OUT at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)

Web Application import the starter won't start due to cyclic bean dependency

The project spring-cloud-common-security-demo demonstrates the problem by including same basic configuration and dependencies as Spring Cloud DataFlow and Spring Cloud Skipper.

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration$EnableWebMvcConfiguration
↑     ↓
|  org.springframework.security.config.annotation.web.configuration.OAuth2ClientConfiguration$OAuth2ClientWebMvcSecurityConfiguration
↑     ↓
|  org.springframework.cloud.common.security.OAuthSecurityConfiguration
└─────┘


Action:

Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.

Not fully compatible with boot2

Making a simple boot app with web and security deps, including this project. Then add simple imports to main class:

@Import({ BasicAuthSecurityConfiguration.class, DefaultBootUserAuthenticationConfiguration.class,
	OAuthSecurityConfiguration.class })

App will fail with:

***************************
APPLICATION FAILED TO START
***************************

Description:

A component required a bean of type 'org.springframework.security.config.annotation.ObjectPostProcessor' that could not be found.


Action:

Consider defining a bean of type 'org.springframework.security.config.annotation.ObjectPostProcessor' in your configuration.

This is same error I'm seeing dataflow when trying to upgrade to boot2.

Re-add support for ExternalOauth2ResourceAuthoritiesMapper

With the migration to Spring Security 5.2.x we added a regression in regards to the
ExternalOauth2ResourceAuthoritiesMapper.

If this is not empty: authorizationProperties.getExternalAuthoritiesUrl() then we should configure the ExternalOauth2ResourceAuthoritiesMapper instead the default DefaultAuthoritiesMapper.

Add Tests for OAuth Authorization Code Security

From @ghillert on May 4, 2017 19:58

As a follow-up to spring-cloud/spring-cloud-dataflow#1465, we need to add tests that verify that authentication via OAuth authorization code is working properly.

Copied from original issue: spring-cloud/spring-cloud-dataflow#1468

please for example with Oauth2 by springcloud (2022.0.0)

provide a demo with Oauth2 by springcloud (2022.0.0)

Add Support for Mapping of Ldap Roles

Add OAuth2AccessTokenProvidingClientHttpRequestInterceptor

Depends on spring-cloud/spring-cloud-dataflow#3418

Upgrade to Spring Security 5.2

@sabbyanandan commented on Mon Aug 05 2019

Now that we have consumable milestones of Spring Security 5.2, let's study what is coming in the upcoming releases, so we can refactor and adapt to it for consistency.

Specifically, look out for whether:

we can support JWT tokens
we can switch to a cleaner OAuth/OIDC model
migration from Spring Security OAuth to Spring Security is complete or not (if not, what is planned in 5.2 vs. 5.3?)
from the backend service standpoint, can the UAA integration coexist or if it needs an update also
we need to plan for deprecations

Make "OpaqueTokenIntrospector" an optional bean

As a developer, while integrating with Azure AD, I notice the OpaqueTokenIntrospector bean is automatically created; however, in Azure AD there's no support for "introspection" endpoint yet, so it needs to be an optional property.

OAuthSecurityConfiguration class creates a OpaqueTokenIntrospector bean, expecting the following additional configuration to be present:

spring:
  security:
    oauth2:
      ...
      resourceserver:
        opaquetoken:
          introspection-uri: http://this.is.wrong:8080/introspect
          client-id: the_client_id_from_the_app_registration
          client-secret: the_client_secret_from_the_app_registration

Acceptance:

Determine what is the best way to optionally require introspection-uri
Adjust the validation rules accordingly
Adjust the test coverage, as well

Resolve been override issues
Ensure proper auto-configuration order for WebSecurityConfigurerAdapter implementations
Adjust pom dependencies to align with boot 2.1

OAuth group claim mapping

Many oauth libs like okta support using role/group claims from a jwt and as scopes those could be mapped into spring security roles.