I have a Spring Boot application which uses SAML for authorization. The Application runs behind a reverse proxy, which terminates the SSL and redirects to the application at localhost:8080 (https://application.com -> http://localhost:808)
I use OpenSamlMetadataResolver to create the SP Metadata for the IDP.
But the generated endpoints in the resulting metadata-file will not contain the https scheme. Therefore the IDP can't validate the ACS and other endpoints.
Is there a way to force Endpoints use HTTPS scheme?
Related
i am currently working on a project where my backend uses Spring Boot, Spring security + keycloak and runs on localhost:8081.
My frontend (svelte) runs on http://127.0.0.1:5173/ and the url http://127.0.0.1:5173/products needs to access data from localhost:8081/products (which needs a login) but the login page from keycloak doesnt appear.
In other words, what i am trying to achieve:
I want that the url http://127.0.0.1:5173/products redirects to localhost:8081/products which redirects to keycloak login page and after a successfull login i want to return to http://127.0.0.1:5173/products where i will be able to see the data.
is there an elegant solution to this problem? Im really stuck on this problem and this is one of my first projects.
Thanks in advance!!
Some OAuth2 wording:
Keycloak is an authorization-server (OIDC complient)
Svelte app is a client
Spring REST API is a resource-server
Ensure that a "public" client is declared in Keycloak.
Configure your Svelte client with an existing OIDC lib (component) of your choice to:
use the "public" client deckared in Keycloak
authenticate users against Keycloak (socket is not the same as spring API)
add an authorization header with a JWT access-token retrieved from Keycloak (when issuing requests to your secured REST endpoints)
Configure Spring API as a secured resource-server with a JWT decoder.
You can refer to this article for configuring Keycloak and resource-server with JWT access-tokens.
I have been exploring APIgee and okta configuration using https://github.com/tom-smith-okta/okta-api-center repo. Here APIgee edge acts as a gateway to https://okta-solar-system.herokuapp.com/ api’s and the token for authentication is generated via okta. My understanding is that https://okta-solar-system.herokuapp.com/ doesnt have any okta authentication enforcement. The check is via apigee.
If I were to replace https://okta-solar-system.herokuapp.com/ with a spring boot application hosted publicly should the application have okta security enabled (eg : https://github.com/oktadeveloper/okta-spring-boot-oauth-example) or should i follow same procedure as above and delegate enforcement of token to apigee, without any security enforcement on the spring boot application?
Can someone tell me what is the standard way of implementation I should follow?
If the spring boot application has no enforcement of security, what is to prevent someone from bypassing the Apigee API gateway and calling it directly?
If you have successfully managed to secure the spring boot application so that only the API gateway can communicate with it (via mutual TLS connection, IP allow listing, etc), you might be able to forego any enforement at the service level, but I would recommend doing some authorization checks in the service itself.
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')")
I'm currently working on a project that uses Zuul to proxy requests to both API endpoints as well as client resources. There is an angular app that is being served from the same endpoint as the Zuul proxy as outlined in this guide. I have the need for additional clients, specifically a desktop application.
I'm not sure I understand how Zuul proxy handles requests and I think there are several paths to get to where I want to go, I'm just not sure what the correct one is.
Here is what I have surmised thus far:
Option 1: Extract the Zuul proxy and SSO capabilities to it's own server. Then create a new UI server which is behind the gateway server. Follow this up with creating a new client application server which handles the authentication of the desktop client.
Option 2: Extract the Zuul proxy and SSO capabilities to it's own server. Serve the current angular app from its own server NOT behind the proxy and change the authorization flow to something different (implicit). Alter Zuul proxy and SSO configuration to ignore requests that already have a bearer token in the header.
If I go with option 2 then I don't understand how to register with the Zuul gateway client that I already am providing the authorization header with my requests so all it should be doing then is proxying my requests to the correct microservices.
Final Questions:
Which option is the most optimal one?
If an access token is already acquired (directly from the auth server using implicit flow) then how does Zuul need to be configured to not try and acquire the access token using the jsessionid?
I have set up the keycloak server and created the spring rest application with keycloak rest adapters. The Authorizations rules are working fine.
I would like to know about the internal working of the keycloak spring boot rest adapter. How the logged in user's token is validated against policy and permission set in keycloak admin client.
You are correct, access token does not contain all these details.
In Keycloak when you are using server side adapters the client will be configured to use the standard flow and not the implicit flow of OIDC.
In standard flow when you login using keycloak IDP your front-end redirects to Keycloak IDP and asks for you credentials. If you have the right credentials login is successful and you are redirected back to your app. In this redirect your app gets a code which it then sends to the back-end rest call. This code is used by spring adapter in the spring boot app to make a call to Keycloak IDP server and it is this call in which the boot application will get the user context to take all the authorization decisions as a response from the Keycloak server.
Hope this makes sense.