Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spring Boot Admin with OAuth2 sample implementation #1262
Spring Boot Admin with OAuth2 sample implementation #1262
Changes from 1 commit
731b746
46e2767
5ebfa45
f5e9524
8cd160e
12fe1c0
3bcd7bd
eb4db57
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this sample should stick to common practices and use the
authorization_code
grant type.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please provide an example flow? As far as I know
authorization_code
grant type is not well-suited for server-to-server authentication, so I try to understand your vision of how it should work step-by-stepThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we both have a different understanding of the whole picture.
In my understanding, a not logged-in user is forwarded to the configured authorization provider by SBA. The authorization token allows the user a) to use SBA and b) to use the actuator endpoints of the client applications. Therefore SBA needs to forward the authorization token in requests made to the underlying applications. This should use the
authorization_code
grant-type.The SBA server does also query some endpoints in the background (e.g.
/health
and/info
). So the SBA server needs to authenticate against the client applications. This authentication should be done via thepassword
grant-type or using basic auth.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I follow this part. Why client applications must require an additional basic authentication in order to expose
/health
and/info
endpoints? Should not those be in the scope of the token?On the other hand, if SBA server is protected by OAuth2 and token is required to use it, how resource server should register itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the SBA server must have a token that allows to access these endpoints. (As alternative it might use some credentials and basic authentication to access those - think of it like an api key - which is imho easier to setup)
Either just the endpoint for registering is left unprotected or the same applies here:
The sba clients either needs a oauth2 token or some other form of credentials for authentication...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prepared an example version with the scenario you proposed, however I encountered problems during testing the solution:
1. Refreshing available actuator endpointsConsider the following scenario:Given:
* Authorization, SBA and Resource servers are up.
* Resource server is protected with OAuth2, but allows accessing to/health
and/info
endpoints with basic authentication.When:
* Resource server registers itself using basic authentication before SBA login is performed and token is obtained.
* SBA (using basic authentication) fetches available actuator endpoints of the Resource server.
* SBA login is performed and token is obtained.Then:
* Requests to the Resource server include Bearer token
* UI does not display all details, but only Metadata and Health
* After restarting Resource server all endpoints are displayedReason:
* It seems like available endpoints are not refreshed after being once fetched.Solution:
* Well, I am not sure if there is a way to trigger a refresh. Please, advice.2. Problem fetching
OAuth2AuthorizedClient
fromHttpHeadersProvider
Put simply, Spring provides a mechanism to fetch client (with token) using client-id and principal, however I can not find a convenient way to obtain a principal.
SecurityContextHolder.getContext().getAuthentication()
returnsnull
when called fromHttpHeadersProvider
.The workaround I found for now is to implement custom in-memory
OAuth2AuthorizedClientService
that is able to fetch any client with suiting scope, however I am not satisfied with the solution.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is due to 2 facts:
Spring Boot Admin makes fetches in the background (without any user interaction). So SBA still need some own token. For these background fetches the easiest way would be to have some kind of basic auth using username/password or an api-token
Spring Boot Admin uses the WebClient for making requests. Due to the reactive nature the request ist executed in a different thread and the ThreadLocal backing the
SecurityContextHolder
is not available.If you just need access to the original headers write a
InstanceExchangeFilterFunction
which has access to the headers from the original request (filtered by theHttpHeaderFilter
and settings fromspring.boot.admin.instance-proxy.ignored-headers
- defaults to"Cookie", "Set-Cookie", "Authorization"
).If you need the principal itself I guess, we could include it to the request attributes passed to the
InstanceExchangeFilterFunction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure that access to the request headers would be enough to solve the problem.
Here is how OAuth2Login works in
Spring 5
. The requests between SBA front and SBA back would be authorized with a Cookie. All tokens obtained from OpenID Connect provider will be stored on the backend and fetched intoAuthentication
object by Spring Security in the context of request processing. So basically this is what you want to do insideHttpHeadersProvider
(pseudo-code):Without having
requestContext
andsecurityContext
defined above I cannot see how theHttpHeadersProvider
could be implemented.