Can't get spring-boot /health indicator to display full content - spring

Trying to get the full content of the /health endpoint. I've set the following:
endpoints.health.sensitive=true
management.security.enabled=true
and I'm successfully authenticating (earlier, to gain access to the endpoint in the first place), as shown by the log snippet below:
2016-11-06 10:48:18,936 [XNIO-3 task-1]DEBUG o.s.c.e.PropertySourcesPropertyResolver - Found key 'endpoints.health.sensitive' in [applicationConfig: [classpath:/application.properties]] with type [String] and value 'true'
2016-11-06 10:48:19,109 [XNIO-3 task-1]DEBUG o.s.s.w.h.writers.HstsHeaderWriter - Not injecting HSTS header since it did not match the requestMatcher org.springframework.security.web.header.writers.HstsHeaderWriter$SecureRequestMatcher#4542ffee
2016-11-06 10:48:19,109 [XNIO-3 task-1]DEBUG o.s.s.w.c.HttpSessionSecurityContextRepository - SecurityContext 'org.springframework.security.core.context.SecurityContextImpl#760f603a: Authentication: org.springframework.security.authentication.UsernamePasswordAuthenticationToken#760f603a: Principal: org.springframework.security.ldap.userdetails.LdapUserDetailsImpl#375540cb: ......; Enabled: true; AccountNonExpired: true; CredentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ......; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails#b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: .....' stored to HttpSession: 'io.undertow.servlet.spec.HttpSessionImpl#768a4e99
2016-11-06 10:48:19,148 [XNIO-3 task-1]DEBUG o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor - Written [UP {}] as "application/json" using [org.springframework.http.converter.json.MappingJackson2HttpMessageConverter#eae8a50]
But one can see by the last line that I'm only being shown the "non-sensitive" information (there are db connections in the app which show up if I set both of the spring-boot properties to false.
From what I've read, the db status should be displayed.
What am I missing?

Possible duplicate of Spring Boot Actuator /health endpoint does not show database or file system information
I think you need to enable db health checks by default
management.health.db.enabled=true # Enable database health check.
management.health.defaults.enabled=true # Enable default health indicators.
management.health.diskspace.enabled=true # Enable disk space health check.
Also there are auto-configured health indicators for various backend implementations by Spring Boot
see: http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#_auto_configured_healthindicators
Hope it helps.

put a breakpoint in HealthMvcEndpoint (https://github.com/spring-projects/spring-boot/blob/master/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/endpoint/mvc/HealthMvcEndpoint.java) and in debug, you'll be able to understand how the health response is built, based on the underlying components exposing health infos and the security config (exposeHealthDetails method).

Add the following property in the properties file to resolve the problem:
management.health.db.enabled=true

Related

Spring Boot: Error publishing SessionConnectedEvent

I have Spring Stomp setup on a project, everything is working fine but I keep getting this as errors in the server logs.
2021-02-17 05:02:26.875 ERROR 23773 --- [oundChannel-914] o.s.w.s.m.StompSubProtocolHandler : Error publishing SessionConnectedEvent[GenericMessage [payload=byte[0], headers={simpMessageType=CONNECT_ACK, simpConnectMessage=GenericMessage [payload=byte[0], headers={simpMessageType=CONNECT, stompCommand=CONNECT, nativeHeaders={x_from_wss=[true], accept-version=[1.1,1.0], heart-beat=[0,0]}, simpSessionAttributes={}, simpHeartbeat=[J#1dbcdf26, simpUser=org.springframework.security.authentication.UsernamePasswordAuthenticationToken#cda212a8: Principal: me.xxxx.xxx.user.security.UserLoginDetails#325d7812; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails#957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Not granted any authorities, simpSessionId=ml2gvecs}], simpUser=org.springframework.security.authentication.UsernamePasswordAuthenticationToken#cda212a8: Principal: me.xxxx.xxx.user.security.UserLoginDetails#325d7812; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails#957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Not granted any authorities, simpSessionId=ml2gvecs}]]
I tried setting up Event handlers for the websocket as well but still it continues to show up in the logs. I understand its an acknowledgement message on the connect from the client but it should not fail. Any advise will be much appreciated.
The error says:
Not granted any authorities
If you are using something like Spring Security, make sure to pass a collection of Granted Authorities, once authenticated.
You could do something like this
UsernamePasswordAuthenticationToken usernamePasswordAuthenticationToken= new UsernamePasswordAuthenticationToken(
"AuthenticatedUserName", "Credentials", Collections.singleton((GrantedAuthority) () -> "USER")
);
In case you are not using Spring Security, you could set up a Authenticated User Token via Channel Interceptor.
Follow thelink below, to see how you can setup Channel Interceptor for you WebSocket Connection
Websocket Authentication and Authorization in Spring

Session attributes missing intermittently - Spring Session + Pivotal GemFire Implementation

Facing a strange issue for sometime in Spring Session with Pivotal GemFire integration.
We have multiple HTTP requests, which eventually does set/get of session attributes in a varying order based on several conditions.
At some given point...
(T) session.getAttribute(sessionKeyN); // (T) is template object
... is retrieving null. We have cross verified that no session.setAttribute(..) is invoked in between two session.getAttribute(..) calls out of which one misses the object.
We enabled trace logging in GemFire client. There we see a mismatch in hashmaps being read/written. Sharing the logs:
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.DataSerializer: **Writing HashMap with 8 elements**: {LOGIN_DATE_TIME=09-24-2018 02:46:08 AM, TERMINAL=terminal.Terminal#5aa33970, org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME=testuser, LOG_TRANSACTION_ID=20180924_451_5_4,20180912045104000005, USER=user.User#70b4b11b, TRANSACTION_HEADER=TransactionHeader#4144221c, XXXX_LOGIN=true, SPRING_SECURITY_CONTEXT=org.springframework.security.core.context.SecurityContextImpl#65bb8fc1: Authentication: org.springframework.security.authentication.UsernamePasswordAuthenticationToken#65bb8fc1: Principal: testuser; Credentials: [PROTECTED]; Authenticated: true; Details: null;}
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.**InternalDataSerializer: basicWriteObject**: {LOGIN_DATE_TIME=09-24-2018 02:46:08 AM, TERMINAL=terminal.Terminal#5aa33970, org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME=testuser, LOG_TRANSACTION_ID=20180924_451_5_4,20180912045104000005, USER=user.User#70b4b11b, TRANSACTION_HEADER=TransactionHeader#4144221c, XXXX_LOGIN=true, SPRING_SECURITY_CONTEXT=org.springframework.security.core.context.SecurityContextImpl#65bb8fc1: Authentication: org.springframework.security.authentication.UsernamePasswordAuthenticationToken#65bb8fc1: Principal: testuser; Credentials: [PROTECTED]; Authenticated: true; Details: null;}
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.DataSerializer: Writing STRING_BYTES of len=8
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.DataSerializer: Writing String "testuser"
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.DataSerializer: Writing STRING_BYTES of len=36
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.DataSerializer: Writing String "5c4948d9-7438-4dff-badc-fdc0f9997781"
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.InternalDataSerializer: basicWriteObject: { #type = org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession, id = 5c4948d9-7438-4dff-badc-fdc0f9997781, creationTime = 2018-09-24T09:44:23.180Z, lastAccessedTime = 2018-09-24T09:46:14.909Z, maxInactiveInterval = PT30M, principalName = testuser }
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.InternalDataSerializer: DataSerializer Serializing an instance of org.apache.geode.cache.Operation
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.InternalDataSerializer: basicWriteObject: UPDATE
>2018-09-24T02:46:15:342-0700 [20180924_451_5_4,20180912045104000005] DEBUG org.apache.geode.cache.client.internal.PutOp: PutOpImpl constructing message with operation=UPDATE
>2018-09-24T02:46:15:144-0700 [20180924_451_5_4,20180912045104000005] DEBUG org.apache.geode.internal.cache.LocalRegion: invoking listeners: [org.springframework.session.data.gemfire.GemFireOperationsSessionRepository#4471a4f]
>2018-09-24T02:46:15:144-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.cache.LocalRegion: dispatchListenerEvent event=EntryEventImpl[op=LOCAL_LOAD_CREATE;region=/XXXX2wl;key=5c4948d9-7438-4dff-badc-fdc0f9997781;oldValue=null;newValue={ #type = org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession, id = 5c4948d9-7438-4dff-badc-fdc0f9997781, creationTime = 2018-09-24T09:44:23.180Z, lastAccessedTime = 2018-09-24T09:46:15.079Z, maxInactiveInterval = PT30M, principalName = testuser };callbackArg=null;originRemote=false;originMember=tstplXXXX0004(ClientConfigXXXX2Application:28299:loner):35884:0c27e20a:ClientConfigXXXX2Application;callbacksInvoked;version={v20; rv161; mbr=10.5.230.71(server_devplgemf0066:123628)<v23>:1024; time=1537782375131; remote};isFromServer]
>2018-09-24T02:46:15:144-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.cache.versions.VersionTag: deserializing class org.apache.geode.internal.cache.versions.VMVersionTag with flags 0x4
>2018-09-24T02:46:15:144-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.internal.InternalDataSerializer: basicReadObject: header=1
>2018-09-24T02:46:15:144-0700 [20180924_451_5_4,20180912045104000005] TRACE org.apache.geode.DataSerializer: **Read HashMap with 9 elements**: {LOGIN_DATE_TIME=09-24-2018 02:46:08 AM, TERMINAL=terminal.Terminal#5a2aa051, **CUSTOMER_SEARCH_RESPONSE=CustomerInfo#600fa25f**, org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME=testuser, LOG_TRANSACTION_ID=20180924_451_5_4,20180912045104000005, USER=user.User#7178708f, TRANSACTION_HEADER=TransactionHeader#30215dcd, XXXX_LOGIN=true, SPRING_SECURITY_CONTEXT=org.springframework.security.core.context.SecurityContextImpl#65bb8fc1: Authentication: org.springframework.security.authentication.UsernamePasswordAuthenticationToken#65bb8fc1: Principal: testuser; Credentials: [PROTECTED]; Authenticated: true; Details: null;}
Attribute CUSTOMER_SEARCH_RESPONSE is missing even though no session.setAttribute(..) for it was invoked.
This is not WRT to one attribute and also not consistent. A re-run might not show this issue.
After working with another Pivotal (GemFire) customer on a similar problem (also using Spring Session and Pivotal GemFire (SSDG) to manage HTTP session state in a highly concurrent Web application/environment), we uncovered the underlying issue(s) and ultimately found BUGS in Pivotal GemFire!
In nutshell, these bugs lead to Lost Updates due to Race Conditions that are exasperated in a highly concurrent (multi-user) Web environment, where multiple HTTP requests might possibly be accessing and modifying the same HTTP session under load. And, the greater the concurrency (users) and the greater the load (number of HTTP requests to the same HTTP session), the more apparent this problem becomes.
In fact, I have written several Integration Tests illustrating this problem.
First, I wrote a Load Integration Test (MultiThreadedClientProxyRegionSessionIntegrationTests). This class spawns 180 Threads (users) performing 10,000 concurrent requests to the same underlying Session. The Session object, though not exactly the same, is modeled after SSDG's GemFireSession object representation.
Second, I wrote another Integration Test (TwoThreadsClientProxyRegionSessionIntegrationTests) that reliably and repeatedly reproduces the problem.
Both of these test classes were written purely with the GemFire API, thereby illustrating that Pivotal GemFire is the problem, not SSDG.
I have written similar test using Spring Session Data GemFire both in my example, and now, also included in the SSDG test suite (along with many other MultiThread/Concurrency based integration tests), itself, ensuring Spring Session (for Pivotal GemFire) will never encounter this problem again, and if it does, I'll know about it sooner than later.
In short, the 2 underlying Pivotal GemFire bugs are:
GEODE-6152
GEODE-6032
The workaround is as follows:
First, you must configure your Spring Session, GemFire cache client application with:
A client PROXY Region to manage the Session state (default)
Set copy-on-read set to true.
And, you must use GemFire DataSerialization, by setting the sessionSerializerBeanName appropriately:
#SpringBootApplication
#ClientCacheApplication(copyOnRead = true, subscriptionEnabled = true)
#EnableGemFireHttpSession(
clientRegionShortcut = ClientRegionShortcut.PROXY,
sessionSerializerBeanName = GemFireHttpSessionConfiguration.SESSION_DATA_SERIALIZER_BEAN_NAME
)
class MySpringBootSpringSessionDataGemFireApplication {
...
}
See here, for example.
You will also need to upgrade to Spring Session for Pivotal GemFire 2.1.2.RELEASE (to be released soon), since I made several important, recent enhancements, such as:
Issue #12 - Prevent SessionRepository.save(Session) on non-dirty Sessions.
Issue #9 - Add server-side configuration support for GemFire/Geode DataSerialization when SSDG is not used to configure Spring Session on the servers.
Issue #17 - Consider support for customizable IsDirty application domain object checking.
Using GemFire DataSerialization with Deltas will not prevent, but greatly reduces the possibility of lost updates and other race condition intrinsically inherit in a Web environment, particularly since a Servlet container (e.g. Tomcat) is multi-threaded, processing each HTTP request in a separate thread.
While SSDG goes to great effort to ensure the HTTP session representation (i.e. GemFireSession) is thread-safe, you must also ensure that any object you put in the HTTP session is also thread-safe since it can and most likely will be accessed by more than 1 thread in a highly-concurrent Web application, especially 1 where more than a single HTTP request can access the same HTTP session (by session ID) at a time.
Anyway, food for thought.
When the configuration above is used, everything works as expected, and when not, lost updates can and will occur dues to the GemFire BUGS!
In fact, my load test revealed that out of 10,000 Session updates, where ~9800 Session attributes get added, only ~1100 successfully are, that is a whopping ~89% loss of data!!!
However, when the configuration above is applied, all data is accounted for correctly.
Hope this helps!

remove OAuth2AuthenticationProcessingFilter from/oauth/token filter chain

I am trying to implement OAuth2 into my Spring Boot app. When making a call to /oauth/token using a password grant, I am able to authenticate using Basic auth with a username/password against a database. The authentication object is loaded into the security context and the filter continues. However I noticed that further down the line the OAuth2AuthenticationProcessingFilter is called and cleans out the security context b/c no OAuth bearer token is found. This ultimately results in an authentication failure at the TokenEndpoint.postAccessToken method (e.g. /oauth/token).
Is it expected that the OAuth2AuthenticationProcessingFilter would be called during a /oauth/token call? If not, any ideas why? If it is expected what is the best fix/work around for this issue, to set stateless on the OAuth2AuthenticationProcessingFilter to false? Not sure if that is a good idea or not...
Some relevant info, I am using xml config for my spring security settings and JavaConfig for the rest. The grant type is password on the /oauth/token call.
Any help is greatly appreciated. Below are some log messages for context on what I am seeing.
09/30/15 22:42:50.899 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.c.ClientCredentialsTokenEndpointFilter - Authentication success. Updating SecurityContextHolder to contain: org.springframework.security.oauth2.provider.OAuth2Authentication#9d98054f: Principal: testUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails#b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_USER
09/30/15 22:42:50.899 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.BearerTokenExtractor - Token not found in headers. Trying request parameters.
09/30/15 22:42:50.899 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.BearerTokenExtractor - Token not found in request parameters. Not an OAuth2 request.
09/30/15 22:42:50.899 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.OAuth2AuthenticationProcessingFilter - Clearing security context.
09/30/15 22:42:50.900 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.OAuth2AuthenticationProcessingFilter - No token in request, will continue chain.
09/30/15 22:42:50.900 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.BearerTokenExtractor - Token not found in headers. Trying request parameters.
09/30/15 22:42:50.900 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.BearerTokenExtractor - Token not found in request parameters. Not an OAuth2 request.
09/30/15 22:42:50.900 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.a.OAuth2AuthenticationProcessingFilter - No token in request, will continue chain.
09/30/15 22:42:50.934 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.e.FrameworkEndpointHandlerMapping - Looking up handler method for path /oauth/token
09/30/15 22:42:50.937 [http-nio-9931-exec-8] DEBUG o.s.s.o.p.e.FrameworkEndpointHandlerMapping - Returning handler method [public org.springframework.http.ResponseEntity<org.springframework.security.oauth2.common.OAuth2AccessToken> org.springframework.security.oauth2.provider.endpoint.TokenEndpoint.postAccessToken(java.security.Principal,java.util.Map<java.lang.String, java.lang.String>) throws org.springframework.web.HttpRequestMethodNotSupportedException]
09/30/15 22:42:50.958 [http-nio-9931-exec-8] INFO o.s.s.o.p.endpoint.TokenEndpoint - Handling error: InsufficientAuthenticationException, There is no client authentication. Try adding an appropriate authentication filter.
09/30/15 22:42:51.070 [http-nio-9931-exec-8] DEBUG o.s.s.w.a.ExceptionTranslationFilter - Chain processed normally
09/30/15 22:42:51.070 [http-nio-9931-exec-8] DEBUG o.s.s.w.c.SecurityContextPersistenceFilter - SecurityContextHolder now cleared, as request processing completed

Deploy Spring Integration in Bitnami Stack

I am stuck with a problem and I can't figure out what is happening...
I have built an rest-api using spring integration. When I deploy the app in my local tomcat 7 everything works OK.
When I deploy it in mi bitnami stack (same tomcat version) and try the same request (changing the host), authentication step is OK but no mapping is found...
Basic authentication wih Spring Security is well done
2013-07-02 12:12:04,228 DEBUG intercept.FilterSecurityInterceptor -
Previously Authenticated:
org.springframework.security.authentication.UsernamePasswordAuthenticationToken#95f956f:
Principal: org.springframework.security.core.userdetails.User#36ebcb:
Username: user; Password: [PROTECTED]; Enabled: true;
AccountNonExpired: true; credentialsNonExpired: true;
AccountNonLocked: true; Granted Authorities: ROLE;
Credentials: [PROTECTED]; Authenticated: true; Details:
org.springframework.security.web.authentication.WebAuthenticationDetails#0:
RemoteIpAddress: 85.136.69.37; SessionId: null; Granted Authorities:
ROLE 2013-07-02 12:12:04,228 DEBUG
vote.AffirmativeBased - Voter:
org.springframework.security.web.access.expression.WebExpressionVoter#346946d5,
returned: 1 2013-07-02 12:12:04,228 DEBUG
intercept.FilterSecurityInterceptor - Authorization successful
Spring Integration mapping is not found
2013-07-02 12:12:04,228 DEBUG intercept.FilterSecurityInterceptor -
RunAsManager did not change Authentication object 2013-07-02
12:12:04,228 DEBUG web.FilterChainProxy -
/ptgapi/v1/clients/1/events/400 reached end of additional filter
chain; proceeding with original chain 2013-07-02 12:12:04,228 DEBUG
support.OpenEntityManagerInViewFilter - Opening JPA EntityManager in
OpenEntityManagerInViewFilter 2013-07-02 12:12:04,229 DEBUG
servlet.DispatcherServlet - DispatcherServlet with name 'Destiny
Customer Information Search Restful Web Service' processing GET request for [//PTG/ptgapi/v1/clients/1/events/400]
2013-07-02 12:12:04,229 WARN servlet.PageNotFound - No mapping
found for HTTP request with URI
[//PTG/ptgapi/v1/clients/1/events/400]
in DispatcherServlet with name 'Destiny Customer Information Search
Restful Web Service'
Any idea what is happening?
Update
I have found that Spring Integration is using a double slash (//) in local and a simple slash (/) in bitnami being the same war.
Could be the way Spring Integration splits the URL (local environment is windows and bitnami is Ubuntu)?
LOCAL
2013-07-02 15:31:28,443 DEBUG servlet.DispatcherServlet - DispatcherServlet with name 'Destiny Customer Information Search Restful Web Service' processing GET request for [/PTG/ptgapi/v1/clients/1/events/400]
2013-07-02 15:31:28,449 DEBUG inbound.UriPathHandlerMapping - Matching patterns for request [/ptgapi/v1/clients/1/events/400] are [/ptgapi/{apiVersion}/clients/{clientId}/events/{eventId}]
BITNAMI
2013-07-02 13:37:45,469 DEBUG servlet.DispatcherServlet - DispatcherServlet with name 'Destiny Customer Information Search Restful Web Service' processing GET request for [//PTG/ptgapi/v1/clients/1/events/400]
2013-07-02 13:37:45,470 WARN servlet.PageNotFound - No mapping found for HTTP request with URI [//PTG/ptgapi/v1/clients/1/events/400] in DispatcherServlet with name 'Destiny Customer Information Search RestfulWeb Service'
I have found that changing servlet-mapping to this one avoid this strange behaviour:
<servlet-mapping>
<servlet-name>Destiny Customer Information Search Restful Web Service</servlet-name>
<url-pattern>/rootCommonPath/*</url-pattern>
</servlet-mapping>

How to retrieve UserDetails with Spring Security 3?

www.someurl.com - public access not intercepted by Spring Security 3.
www.someurl.com/admin - intercepted by Spring Security 3. Works fine.
I log into a page under www.someurl.com/admin. Then I change the url to www.someurl.com in the same window tab. I am working within the same http session so I expect to be able to retrieve user login details.
The public url request is handled by a dedicated controller. Within this controller, I have a wired user service. The implementer of this service is attempting to retrieve credentials but can't - Authentication object is null.
Authentication a=SecurityContextHolder.getContext().getAuthentication();
userDetails=(UserDetails) a.getPrincipal();
=== UPDATE =========================
When I inspect the HttpSession in the public url request controller, I see this attribute:
{SPRING_SECURITY_CONTEXT=org.springframework.security.core.context.SecurityContextImpl#ed20eaf7: Authentication: org.springframework.security.authentication.UsernamePasswordAuthenticationToken#ed20eaf7: Principal: org.springframework.security.core.userdetails.User#586034f: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ADMINISTRATOR,AUTHOR,EDITOR,READER; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails#380f4: RemoteIpAddress: 127.0.0.1; SessionId: 43A582157C5813018632ACDD7499CF7D; Granted Authorities: ADMINISTRATOR, AUTHOR, EDITOR, READER}
If you want to get security details like you are, Spring Security must intercept the url, otherwise there won't be any security information. You can add the following to your spring security config:
<security:http pattern="/" security='none' />
This means that spring security will let everyone see the root url (whether logged in or not), but spring security will process the url, meaning your controller against the root url will be able to get the current user login details from SecurityContextHolder

Resources