What's new

Micronaut Security 2.0.0 includes the following new features and improvements.

Annotation Processing

• The @Secured annotation has been moved to a separate module in order to reduce the number of classes in the annotation processor scope. If you currently have micronaut-security in the classpath of your compiler, the entry can be changed to micronaut-security-annotations.

Improvements

• A new constructor for AuthenticationFailed that takes a string message has been added to allow for custom error messages.

• It is now possible to require all AuthenticationProviders to return a successful authentication response. Set micronaut.security.authentication-provider-strategy: ALL to enable this functionality.

• The token propagation implementation will now no longer override an existing token.

• It is now possible to allow for requests that would normally result in a 404 to return with 404 instead of almost always returning a 401 or 403. The current behavior is still the default because it prevents attackers from discovering what endpoints are available in your application. To enable the alternative behavior, set micronaut.security.reject-not-found: false in your configuration.

• It is now supported out of the box to redirect back to the prior URL after a successful login. If a user requests a URL that returns an unauthenticated response, after logging in successfully, the user can then be returned to the URL that previously returned unauthorized. This setting can be enabled with micronaut.security.redirect.prior-to-login: true in your configuration. It is disabled by default.

• Support for using tokens directly from OpenID providers has been added. By default the information from the OpenID JWT token is used to create a new token that uses Micronaut's JWT settings. This allows for a common format across providers as well as standardized expiration. Some users may want to use the token coming from the provider directly. That is now supported with the configuration option and value micronaut.security.authentication: idtoken. Note that this authentication mode requires each application to implement any necessary refresh token functionality. The refresh token functionality in this library is specific to the tokens created by this library.

• The TokenValidator API now has access to the current request.

Breaking Changes

This section will document breaking changes that may happen during milestone or release candidate releases, as well as major releases eg (1.x.x -> 2.x.x).

2.0.0

New Maven Group ID

The Maven Group ID has changed from io.micronaut to io.micronaut.security.

Modules Enabled by default

• Modules are now enabled by default. The configuration keys micronaut.security.enabled, micronaut.security.token.jwt.enabled, micronaut.security.oauth2.enabled, and micronaut.security.session.enabled are now all true by default.

Endpoints enabled by default

• You don't need to enable Endpoints. The configuration keys micronaut.security.endpoints.keys.enabled, micronaut.security.endpoints.login.enabled, micronaut.security.endpoints.logout.enabled, micronaut.security.endpoints.oauth.enabled are now all true by default. However, You will need to provide the required beans for each endpoint.

UserDetails deleted in favour of Authentication

UserDetails has been removed. Every api which previously used UserDetails uses Authentication instead. Authentication provides several static build methods to creates instances of Authentication for a particular user.

io.micronaut.security.oauth2.endpoint.token.response.OauthUserDetailsMapper has been renamed to io.micronaut.security.oauth2.endpoint.token.response.OauthAuthenticationMapper

io.micronaut.security.oauth2.endpoint.token.response.OpenIdUserDetailsMapper has been renamed to io.micronaut.security.oauth2.endpoint.token.response.OpenIdAuthenticationMapper.

io.micronaut.security.oauth2.endpoint.token.response.DefaultOpenIdUserDetailsMapper renamed to io.micronaut.security.oauth2.endpoint.token.response.DefaultOpenIdAuthenticationMapper.

Authentication Provider

• The AuthenticationProvider API has changed to include the HTTP request as a parameter. Thus, it is now possible to gain access to the request in your AuthenticationProvider. Simply override the default method in the interface that takes the request as an argument with your own implementation. The old method is no longer called from the framework.

• It is no longer assumed that a failed authentication response is an instance of AuthenticationFailed. That now allows for any subclass of AuthenticationResponse to be emitted in the case of an authentication failure.

• Previously AuthenticationProviders were allowed to return hot observables, meaning the logic to authenticate the user could be done upon execution of the method. Allowing for that behavior caused the logic to execute the authenticators to be difficult to maintain. Now providers must return cold observables. The authenticate method will be executed for every authentication provider for every authentication request. If you were previously doing the authentication work then using something like Flowable.just, you must use something like Flowable.create to create a cold observable.

Delegating Authentication Provider

• The DelegatingAuthenticationProvider and it's related interfaces has been removed. If you provided implementations for UserFetcher, UserState, PasswordEncoder, and AuthoritiesFetcher, integrate them into your own implementation of api:security.authentication.AuthenticationProvider[]. This API was removed because it only served a niche use case and increased the surface of this library's API. None of the classes mentioned were directly used in this library and thus belong in the realm of user's applications. Check LDAP and Database authentication providers tutorial to learn how to write a DelegatingAuthenticationProvider.

LdapAuthenticationProvider

The constructor for LdapAuthenticationProvider has been changed to accept an executor to schedule the LDAP lookup operation on. By default it is now scheduled on the IO thread pool.

LoginHandler

• The LoginHandler API has changed to accept an api:security.authentication.AuthenticationResponse[] object instead of an AuthenticationFailed.

• Previously, AccessRefreshTokenLoginHandler was enabled by default. Currently, no LoginHandler is enabled by default. If you wish to use any of the built-in LoginHandlers, you have to set the configuration:

** micronaut.security.authentication: bearer to enable AccessRefreshTokenLoginHandler
** micronaut.security.authentication: cookie to enable JwtCookieLoginHandler
** micronaut.security.authentication: session to enable SessionLoginHandler
** micronaut.security.authentication: idtoken to enable IdTokenLoginHandler

Migration Example A

If you were using the default bearer authentication, you should set:

micronaut:
    security:
        authentication: bearer

Migration Example B

For a previous configuration such as:

micronaut:
    security:
        token:
            jwt:
                bearer:
                     enabled: false
                cookie:
                     enabled: true

use instead:

micronaut:
    security:
        authentication: cookie

LogoutHandler

• To use any of the built-in LogoutHandler you have to set the configuration:

** micronaut.security.authentication: cookie or idtoken to enable JwtCookieClearerLogoutHandler
** micronaut.security.authentication: session to enable SessionLogoutHandler

Refresh Token

The story around refresh tokens has been changed. There were a couple of core issues with the old implementation that needed resolved.

• The refresh tokens were JWT tokens which also allowed them to be used to access resources.
• Because they never expire (by default), it requires a list of invalid tokens to be maintained in perpetuity if the ability to revoke tokens is a requirement. JwtGeneratorConfiguration#getRefreshTokenExpiration is deprecated and it is no longer used.
• The refresh mechanism simply copied the claims from the refresh token JWT back into a new access token. This made any changes to the state of the user (new roles, etc) were not be applied at the time of refresh.

The functionality has now been changed to generate a token that is not a JWT, but is instead a signed token of a unique key. The default implementation signs a UUID with a secret provided via configuration. After the token is generated, it is up to each application to provide an implementation of RefreshTokenPersistence to store the token and link it to the user it was created for. That is essential to generate new claims information in new access tokens created by the refresh endpoint. See the refresh section for more information.

Rejection Handler

• The legacy rejection handler in the session module, which was enabled by default, has been removed. The setting micronaut.security.session.legacy-rejection-handler no longer has any effect and is equivalent to the behavior of false in previous versions.

• The entire RejectionHandler API and its dependents have been removed in favor of using the built in exception handling API in Micronaut. An AuthorizationException will now be emitted when access to a resource has been rejected. A default exception handler has been created that will redirect on forbidden or unauthorized if the accept header of the request allows for text/html. For bearer authentication, that behavior can be disabled with:

micronaut.security.redirect.forbidden.enabled: false
micronaut.security.redirect.unauthorized.enabled: false

Basic Auth

• Basic authentication configuration has moved from micronaut.security.token.basic-auth to micronaut.security.basic-auth. The implementation surrounding basic authentication has changed and some classes have been deleted. If you have not overridden any beans related to basic authentication, the functionality will remain the same as it was. Previously a TokenValidatedEvent was triggered as a result of basic authentication, however that is no longer the case.

TokenPropagation

Several classes related to token propagation have been renamed and relocated:

Read token propagation section to learn more.

Misc

• Several APIs that lacked generics have been changed to add them. For example HttpRequest -> HttpRequest<?>.

• Several APIs have been changed to return MutableHttpResponse instead of HttpResponse.

• The SecurityFilterOrderProvider API has been deleted in favor of the standard ServerFilterPhase class. The security filter will now run on the order defined by the SECURITY phase.

• The io.micronaut.security.token.jwt.signature.secret.SecretSignatureFactory was deleted because the beans can be created directly from the SecretSignature class.

• AccessRefreshTokenGenerator is now the interface which defines how generate a AccessRefreshToken for a particular user. The implementation has been moved to DefaultAccessRefreshTokenGenerator.

Deprecated

• All deprecations present in 1.3.x have been removed.

• JwtGeneratorConfiguration has been deprecated in favor of AccessTokenConfiguration. The configuration has been changed from micronaut.security.token.jwt.generator.access-token-expiration to micronaut.security.token.jwt.generator.access-token.expiration.

Redirection

• Redirection configuration has been simplified. The properties in the first column are deprecated and will be removed in a future version. The properties on the right should be used instead. All properties are prefixed with micronaut.security.

v2.0.0 (2020-06-24)

Full Changelog

Merged pull requests:

• [security] Update common files for branch master #291 (@micronaut-build)

* This Changelog was automatically generated by github_changelog_generator