We are using Spring Boot v2.0.4 + Spring Cloud (Finchley release).
We have deployed Zuul, Auth Server, Eureka, and Config Server, each in their own separate applications / processes. We have half a dozen of our own services deployed. We are using OAuth2 authentication for all services. We are using the embedded undertow container for all apps.
When Zuul uses the embedded Undertow container, we can not log in- the login page is redisplayed even though the credentials are correct. When Zuul is switched to use the embedded Tomcat container, everything works correctly- logging in brings the user to the correct page. (All other apps use Undertow in both cases.)
When we debug the requests coming through Zuul for Tomcat vs Undertow, we see that the SPRING_SECURITY_CONTEXT session attribute is being set for Tomcat but is not being set for Undertow. I assume this means that the user will be redirected back to the login page, which is why we are seeing that behavior.
We know that it is an issue with Zuul + Tomcat vs. Undertow, since the configuration of all other apps remains exactly the same.
Any ideas? We are really scratching our heads over this one.
It turned out this was caused by JSESSIONID cookie name conflict between Zuul and Auth Server. Because Tomcat container has different handling than Wildfly for multiple Set-Cookies of the same name (which is in violation of RFC6265), we are only seeing it now.
I should have mentioned that we configured auth server to be behind the Zuul proxy, hence the multiple JSESSIONID cookies.
We fixed this for now by renaming the JSESSIONID cookie name on all back-end servers. We will investigate the best way to do this for production deployment going forward, perhaps by using Spring Session. Any suggestions welcome.
Related
I have created a sample SOAP Web Service project (spring boot) and trying to integrate Okta as a resource server for authentication.
I am able to deploy the application to WebLogic, but when testing the service using SOAP UI, it gives the response even when there is no Token included in the header.
When I access WSDL from a browser using my wsdl url, http://myhost:port/appservice/app.wsdl I see the 401 error, so I think it is picking up the Security config changes. But it is not working for SOAP requests, I would get response even with out Okta token.
Is it because for SOAP requests, do I need to include any interceptors on top of Security Config java file. Or am I taking a wrong path for security with SOAP. Can someone let me know what am I missing or point me to right direction. Is token validation part of WS-Security? or the authentication manager in Okta resource server enough for this?
I followed this documentation to create it.
I have read most of the SO questions related to this and spring documentation, but could not connect the missing dots. Please help me with this. After spending lot of time, I felt like I was moving in circles.
UPDATE:
I have enabled spring security debug logs by doing below
#EnableWebSecurity(debug=true)
logging.level.org.springframework.security.web.FilterChainProxy=DEBUG
UPDATE2:
I haven't made any big changes to my configuration, but when I ran the project on embedded tomcat locally, it started working. To run on Tomcat, I changed packaging from war to jar, excluded Tomcat in my POM and in my Main class, I had to remove the SpringBootServletInitializer and WebApplicationInitializer. That's it. I tested SOAP UI with the Okta bearer token and it gave me response. With out the token it did not give me response.
Spring Security not working only in case of WebLogic12c. I don't know what I am missing to include for that to work in WebLogic. when deployed through Tomcat, request is passed through all the beans in Security Filter Chain {
WebAsyncManagerIntegrationFilter,
SecurityContextPersistenceFilter,
HeaderWriterFilter,
CsrfFilter,
LogoutFilter,
BearerTokenAuthenticationFilter,
RequestCacheAwareFilter,
SecurityContextHolderAwareRequestFilter,
AnonymousAuthenticationFilter,
SessionManagementFilter,
ExceptionTranslationFilter,
FilterSecurityInterceptor}
But on WebLogic, the request is passed only through first four beans in Security Filter Chain {WebAsyncManagerIntegrationFilter,
SecurityContextPersistenceFilter,
HeaderWriterFilter,
CsrfFilter}
I just wanted to update the alternate solution I found for this problem, for completeness.
Spring Security Filter chain was not working for Weblogic, where as same was working in Tomcat, even for Weblogic version 12.2.1.4.
I had followed this example, and implemented Okta filter as spring boot version was not working in Weblogic 12.2.1.4.
Thanks to #Toerktumlare, I have implemented logging with logback-spring.xml
I have built two keycloak clients (spring-client and a tomcat-client using keycloak OIDC spring boot adapter and OIDC tomcat adapter) and both are working in the same realm. I have two problems with these clients.
When I am going to sign in to those clients, I need to provide username and password for each client separately even though I am using the same browser (multiple tabs) and same username.
When i need to sign out only a single client (tomcat-client) log out and the other client (spring-boot-client) does not logout at all and keep the session until a timeout occurs.
Further when I am investigating I found that there are two separate sessions created for both clients. (see the image)
Since I am using same realm and same user I have no idea that how two sessions were created. There is another thing I noticed, tomcat-client & security-admin-console both clients are in the same session. When I logout from the keycloak admin console then tomcat client automatically logs out. The problem is only with the spring-boot client.
Also I have set each client's admin URL as the base URL of each application.
Can someone help me to sort this out.
Thank you
After lots of debugging finally I found the problem in my configuration.
In the spring boot adapter configuration file I have mentioned the Keycloak URL as http://127.0.0.1:8080/auth
In the other adapter configuration file I have mentioned it as http://localhost:8080/auth
the issue was fixed once same URL added for both adapter configurations.
Our stack includes the following services, each service runs in a docker container:
Front-end in React
Backend service based on Spring boot "resource-service"
Keycloak
Other backend service (consumer)
Both the front-end and the consumer services communicate with the backend using REST API.
We use Keycloak as our user management and authentication service.
We would like to integrate our Spring based service "resource-service" with Keycloak by serving both web application and a service flows:
Web application - React based front-send that should get a redirect 302 from the "resource-service" and send the user / browser to login in the Keycloak site and then return to get the requested resource.
Server 2 Server coomunication - A server that need to use the "resource-service" API's should get 401 in case of authentication issues and not a redirection / login page.
There are few options to integrate Spring with Keycloak:
Keycloak Spring Boot Adapter
Keycloak Spring Security Adapter
Spring Security and OAuth2
I noticed that there is a "autodetect-bearer-only" in Keycloak documentation, that seems to support exactly that case. But -
There are a lot of integration options and I'm not sure what is the best way to go, for a new Spring boot service.
In addition, I didn't find where to configure that property.
I've used approaches one and two and in my opinion, if you are using Spring Boot, use the corresponding adapter, use the Spring Security adapter if you're still using plain Spring MVC. I've never seen the necessity for the third approach as you basically have to do everything on your own, why would anyone not use the first two methods?
As for using the Spring Bood adapter, the only configuration necessary is the following:
keycloak:
bearer-only: true
auth-server-url: your-url
realm: your-realm
resource: your-resource
And you're done. The bearer-only is so that you return 401 if a client arrives without a bearer token and isn't redirected to a login page, as you wanted. At least that's what's working for us :-)
After that, you can either use the configuration for securing endpoints but it's a bit more flexible to either use httpSecurity or #EnableGlobalMethodSecurity which we're doing with e. g. #Secured({"ROLE_whatever_role"}).
If you're using the newest Spring Boot version combined with Spring Cloud, you might run into this issue.
I configure my resource-servers to always return 401 when Authorization header is missing or invalid (and never 302), whatever the client.
The client handles authentication when it is required, token refreshing, etc.: Some of certified OpenID client libs even propose features to ensure user has a valid access-token before issuing requests to protected resources. My favorite for Angular is angular-auth-oidc-client, but I don't know which React lib has same features.
Keycloak adapters for Spring are now deprecated. You can refer to this tutorials for various resource-server security configuration options. It covers uses cases from most simple RBAC to building DSL like: #PreAuthorize("is(#username) or isNice() or onBehalfOf(#username).can('greet')")
We are currently developing a microservice application using Spring Boot 1.4 and Keycloak 2.5.0 (configured as openid-connect service) using the Keycloak Spring Adapter (not the Spring Boot adapter).
All of our microservices are put behind a load balancer and an additional reverse proxy as the application will be hosted on an existing domain behind a context root (so the root of our application is http://foo.bar/foobar/ and the rest services are http://foo.bar/foobar/rest/).
We are facing a couple of problems with Keycloak in this given scenario:
Keycloak forward to /sso/login if a sign-in is needed. This is in our case unwanted behaviour because http://foo.bar/sso/login will not exist. I have found a way to change the forward but there is no way to make Keycloak listen to the same url; we end up with a 404 in this case.
After signing in, Keycloak redirects back to the /sso/login url with the correct tokens, but if this is not the same server, the request fails and it redirects us to http://foo.bar/. Since every microservice exposes /sso/login, this can be in fact a completely different server.
If keycloak is hosted on the same domain, we end up in a redirect loop. We would also like to have Keycloak hosted on the same domain and on the context root http://foo.bar/foobar/auth/ .
We've already tried using the "token-store": "cookie" but this did not resolve the problem.
Is there a way to resolve these problems or is Keycloak maybe not the correct solution for our use-case ?
Update 05/05/2017:
Move my answer from here to an answer
We are now up and running with Keycloak so I'll briefly explain what we did. The front-end of our application runs Angular2 and we created a custom login page in the Angular application itself (so it's not a theme for Keycloak) which will directly query the Keycloak API for an OAuth2 Bearer token. The front-end will send this token on each request in the Authorization header (as per the OAuth standards).
On the service side we have configured keycloak as a bearer-only solution (bearer-only: true in the keycloak.json), this way the application just returns a 401 or a 403 instead of forwarding to the login page.
Using this configuration the user will never see anything from the /sso/login page and there is also no redirect issue anymore.
TLDR; the use-case I described was also not realistic, calling a REST URL and then forwarding to a login page is kind of bad stuff :)
Based on an answer from #andy-wilkinson to a past Spring Boot question, it appears that with the exception of a couple parameters (port for example), the management server leverages the same configuration as the regular servlet container.
I would like to configure the main Spring Boot server to use HTTPS (for the application/service it is serving) and to use just HTTP for the actuator endpoints. Has anyone done this? Is this even possible?
-Joshua
It's not possible at the moment. Please open an issue if it's an enhancement that you'd like to see.