Since RC1 is right around the corner, let's change the API
footprint as little as possible by using reflection to check
if a class has declared toBuilder themselves. If they have, we
can assume that that class's builder will produce that class.
Issue gh-18052
This reverts commit 95644fb73c, reversing
changes made to fbf7bb3be1.
Reverting this commit will allow us more time to
consider the ideal way to add this support to the public API.
Leaving the Builder in Authentication allows
authentication implementations to implement Builder
without needing to implement BuildableAuthentication.
Issue gh-18052
This commit consolidates logic common to applying one
authenticaiton to another. Specifically, it will copy the
authorities in one authentication into the builder instance
of another.
Closes gh-18053
This allows the authorization logic to be relaxed so that if RequiredFactor
only has an authority specified, then the GrantedAuthority can be of any
type.
Closes gh-18031
Previously GrantedAuthorities had an implicit package tangle because it
was located in ~.core and FactorGrantedAuthority is in ~.core.authority
and FactorGrantedAuthority's authority property was implicitly expected
to be constants found in `GrantedAuthorities`.
This commit moves the constants to the FactorGrantedAuthority which
resolves this tangle. It wasn't initially done because
FactorGrantedAuthority did not exist at that time.
Closes gh-18030
This commit adds AuthorizationManager<T> additionalAuthorization to
DefaultAuthorizationManagerFactory which can be used for multi factor
authorization.
There is a builder that allows for creating an instance that requires
static additional authorities, but for more advanced cases users can
inject an additionalAuthorization that looks up if the user has settings
that enable additional required authorities.
The builder can later be updated to support checking that a particular
authority was granted within a specified amount of time.
Issue gh-17900
This commit adds a couple of utility methods for working with authorities
by type. Now that there are infrastructural authorities that Spring Secuirty
works with directly, it's helpful to be able to filter them out of the
authority list.
It would be better to introduce parameter types for
principal and credentials into Authentication.Builder
at the same time as doing so for Authentication
Issue gh-17861
This commit allows a default implementation of
Authentication.Builder that performs the builder
operations. In this way, authorities and other previous
authentication material can still be effectively be
propagated in the event a custom authentication does
not implement the method.
Issue gh-17861
Given that the filters are the level at which the
SecurityContextHolder is consulted, this commit moves
the operation that ProviderManager was doing into each
authentication filter.
Issue gh-17862
- Added remaining properties
- Removed apply method since Spring Security isn't using
it right now
- Made builders extensible since the authentications are
extensible
Issue gh-17861
This commit allows looking up the current authentication and applying
it to the latest authentication. This is specifically handy when
collecting authorities gained from each authentication factor.
Issue gh-17862
This commit adds a new default method to Authentication
for the purposes of creating a Builder based on the current
authentication, allowing other authentications to be
applied to it as a composite.
It also adds Builders for each one of the authentication
result classes.
Issue gh-17861
Previously Supplier<@Nullable Authentication> was used. This prevented
Supplier<Authentication> from being used. The code now uses
Supplier<? extends @Nullable Authentication> which allows for both
Supplier<@Nullable Authentication> and Supplier<Authentication>.
Closes gh-17814
Josh Cummings
parthokr
Rob Winch
Andrey Litvitski
Steve Riesenberg