I’m maintaining an application, which is using the Keycloak Spring Security adapter. Now that Keycloak deprecated their adapter, without providing a migration guide, I had to find a solution.
If you’ve been working with Spring Security for a while, it should come as no surprise that from time to time, they deprecate the old, and guide you towards the new.
In 5.7.x such a change involves the often used WebSecurityConfigurerAdapter.
In Spring Security 5.7.0-M2 we deprecated the WebSecurityConfigurerAdapter, as we encourage users to move towards a component-based security configuration.
And while there are blog posts, release notes, and even an instruction video to highlight the required changes, in the end you will have to change your code. But what all those sources so far have failed to cover, is that there’s now also an easier way to migrate your code, using OpenRewrite.
Adding Spring Security to an existing application can be quite a daunting prospect. Merely adding the required dependencies to your project sets off a chain of events which can break your application and tests.
Maybe you’re suddenly shown a login prompt which expects a generated password logged on startup.
Maybe your tests now get the dreaded 401 Unauthorized, or a subsequently a 403 Forbidden.
Maybe you get a ClassCastException when trying to use your Authentication#getPrincipal().
Either way, this post is here to help!
When combined with Spring Security 5.2+ and an OpenID Provider such as Keycloak, one can rapidly setup and secure Spring Cloud Gateway for OAuth2 resource servers.
Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.
We consider this combination a promising standards-based gateway solution, with desirable characteristics such as hiding tokens from the client, while keeping complexity to a minimum.
You might have a need for a custom access decision voter when security decisions are made based on who is accessing what domain object. Luckily Spring Security has quite a few options for such implement such access control list (ACL) constraints.
This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.
Often you’ll find access decisions move beyond simplistic ownership or having a certain role, for instance when users share domain objects with other users. In such cases it’s common to separate permission to view an instance from being able to make changes to the same instance. When your access rules are relatively straightforward, Spring Security offers the PermissionEvaluator interface to secure instance access.
This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.
Spring Data repositories allow you to easily query your entities with method names such as findByUserName(String name).
However, it can get cumbersome to always retrieve, pass and match on the active user.
Luckily Spring Security integrates well with Spring Data to minimize the overhead.
This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.
Spring Data enables you track who modified an entity and when, with just a few annotations. When combined with Spring Security, you can set this metadata based on the active user.
This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.
