I am trying to configure my Spring application to communicate with a third party IDP. My spring application is accessed through an Apache Webserver. However the Spring SAML extension automatically inserts the local address as the Assertion consumer address. This means that the IDP will not send the response through the Apache server.
Been struggling on it for 1 week. Came here only because I did not find an identical question posted.
Related
Currently in developer training, I am working on a personal project on spring. I started java 6 months ago, so there is a certain notion that I do not yet master. My trainer does not know spring at all, so he cannot help me.
I am also French and there is very little reliable documentation on spring (it is evolving quickly).
For example, I followed a French tutorial on microservices, and I used the ribbon and zuul proxy while they are currently in maintenance at spring. I started all over (new project) to recode in reactive webflux
I have several concerning spring starter security or spring cloud security
Spring cloud config (in connection with gitlab)
eureka server
admin server
gateway
2 business microservices
2 sub-module (model and repository)
I want all my microservices and the internal microservices (eureka, admin server, configserver) to be secure now. But I do not know how.
I want the microservice that consults config-server to identify themselves, and I also want the microservice gateway to identify itself to make requests to other microservices. Finally I want all my microservices to be protected.
Should we put spring-starter-security in microservice? Should we create a new microservice with spring-cloug-security?
Should we create a new spring-cloud-security microservice and add spring-start-security everywhere?
https://cloud.spring.io/spring-cloud-security/2.2.x/reference/html/ Obviously I find this link not very explanatory
Thank you
In a microservice architecture that I have worked, we have always used the OAUTH2 specification for securing service.
OAuth2 is a token-based security framework that allows a user to authenticate themselves with a third-party authentication server. If the user successfully authenticates, they will be presented with a token that must be sent with every request. The token can then be validated back to the OAuth2 Server. The OAuth2 Server is the intermediary between the application and the services being consumed. The OAuth2 Server allows the user to authenticate themselves without having to pass their user credentials down to every service the application is going to call on behalf of the user.
Detail information for OAuth2 you can find in the following LINK .
I have implemented simple microservice architecture for demonstrating how services are connected with each other.
Here is the link LINK
Below is the image representing the architecture:
is possible create authorization server for PKCE authentication in current version of spring security?
I did research and I found out this authorization server project https://github.com/spring-projects-experimental/spring-authorization-server but there is no usable sample for that project.
I also find out that spring recommends Keycloak as authorization server, but it is not fit for my case.
We need be able fetch and verify user against remote service, and then use authorization server only for generating and verifying jwt tokens. In my knowledge Keycloak should holds also users right? So the best solution would be custom spring standalone authorization server. Is it possible in some way? Thank you!
You may have a look to this project: CloudFoundry User Account and Authentication (UAA) Server.
UAA is a (Spring MVC) component of Cloud Foundry but it could be used as a stand alone OAuth2 server. It can support external authentication service. And there is a Pull Request that implements PKCE: https://github.com/cloudfoundry/uaa/pull/939 (not yet merged, but under review).
You can find an example on how to use UAA on baeldung.com.
As far as I know, Spring framework has one more implementation of the authorization server. It is a part of spring-security-oauth project. But this project was moved into maintenance mode.
According to this migration guide, the new authorization server project (that you have already found) will be created to change the legacy solution.
From my point of view now there are several possible options:
Using old legacy spring-security-oauth. More examples with old auth server
Using external services like Keycloak, Auth0, Okta and etc
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')")
Background: my web-app is running in PROD, and real users are using it. The initial authentication was implemented using Spring Basic Security.
Recently, client decided to use SSO for authentication, so my app should act as SP with client IdP. I used Spring SAML to configure my app as SP.
Integration with client IdP on QA environment involved next steps:
Get and store IdP metadata file received from customer.
Deploy code with SP configuration on the environment.
Generate SP metadata file using /saml/metadata endpoint and share it with customer.
Get a green light from customer IdP side that SP metadata file in a right place.
Verify that SSO is working successfully.
Now, It's time to deploy SP SSO configuration on PROD environment and integrate it with client PROD IdP.
I don't like to use the approach above for PROD, as real users will not be able to login into the app until app SP metadata file will be generated, and put in a right place at customer IdP.
Can anyone tell me how can I generate SP metadata file for my app in advance, before deploying SSO configuration on PROD?
(1) Quote "Recently, client decided to use SSO for authentication, so my app should act as SP with client IdP. I used Spring SAML to configure my app as SP."
Response:
I suppose that you use Spring SAML provided by the official GitHub repository of Spring Security SAML to "configure your app as SP".
(2) Quote "Integration with client IdP on QA environment involved next steps:.."
Response:
The five (5) steps (provided by your post) regarding integration of your web app as SP with client IdP are the practical SAML standard for "deploying SP SSO configuration on PROD environment and integrate it with client PROD IdP."
I have shared hands-on experience on integration of web app as SAML SP with SAML IdP by providing my answer to another recent Stackoverflow question "I have provided an instruction to address another Stackoverflow How can I generate metadata file of my Java Spring Application to establish a connection with Identity Provider like Ping Federate?"
(3) Quote "I don't like to use the approach above for PROD, as real users will not be able to login into the app until app SP metadata file will be generated, and put in a right place at customer IdP."
Response:
If you "don't like to use the approach above for PROD", you can modify the source code of "spring-security-saml/samples/boot/simple-service-provider/" (provided by the official GitHub repository of Spring Security SAML) to configure your web app as SAML SP.
(4) Question "Can anyone tell me how can I generate SP metadata file for my app in advance, before deploying SSO configuration on PROD?"
Answer:
(I) The README on "How to run a simple sample of an Identity Provider (IDP) and Service Provider (SP)" (provided by the official GitHub repository of Spring Security SAML) will guide you "how can I generate SP metadata file for my app in advance, before deploying SSO configuration on PROD".
(II) I highlight the related information on "how to generate SAML SP metadata file of Spring Basic Security for my web app in advance, before deploying SSO configuration on PROD" (Quote your question).
Step 2 - Start the Service Provider
Service Provider runs on http://localhost:8080/sample-sp
$git clone https://github.com/spring-projects/spring-security-saml
$cd spring-security-saml
$./gradlew :spring-security-saml-samples/boot/simple-service-provider:bootRun &
(II.a) Launch a web browser to access the URL http://localhost:8080/sample-sp
to ensure that Spring Security SAML Service Provider runs well.
(II.b) Launch a web browser to access the SP metadata endpoint
http://localhost:8080/sample-sp/saml/sp/metadata
to download or "generate SP metadata file for my app in advance, before deploying SSO configuration on PROD" (Quote your question).
(5) Question "Spring SAML: alternative ways to generate SP metadata besides using /saml/metadata endpoint"
Answer:
you can modify the source code of "spring-security-saml/samples/boot/simple-service-provider/src/main/java/sample/config/SecurityConfiguration.java" (provided by the official GitHub repository of Spring Security SAML) to "generate SP metadata besides using /saml/sp/metadata endpoint".
For example, if you want to generate SP metadata from a specific endpoint such as /example/metadata, then you just need to replace
"super("/saml/sp/", beanConfig);"
(in the source code shown below) with
"super("/example/", beanConfig);"
public SamlSecurity(BeanConfig beanConfig, #Qualifier("appConfig") AppConfig appConfig) {
super("/saml/sp/", beanConfig);
this.appConfig = appConfig;
}
As long as you know the URIs of the endpoints and the signature certificate you can generate them manually and specify it in the configuration.
We are currently developing an application for a customer. The project has the restriction that we shall deliver only deployable WAR files. The customer provides the infrastructure and doesn't allow much deviation from it.
The application is developped with Spring Boot, Spring Security and SAML. The current version is a single monolithic WAR file.
At the moment, we are in the process of splitting this monolithic application in separate applications because of multiple reasons (maintainability, deployment, code quality, ...). Unfortunately we do not know yet how to implement authorization with these given restrictions:
Infrastructure constraints:
Applications will be deployed on JBoss EAP 7.0
A custom Identity Provider is provided by the customer
Communication with IdP has to be implemented with SAML 2.0
The custom IdP has the following restrictions:
Authentication is done through a proxy, which means only authenticated users arrive at the application
Only one SP metadata file can be provided, because it is linked to the user database. We want to share the same user database for all applications.
The SP metadata file can only provide one AssertionConsumerService-Location
The AssertionConsumerService-Location is statically defined in the metadata file and cannot be overriden in an AuthnRequest
Problem description:
Each application has to authorize itself with the IdP to receive roles and assertions. With the current (monolithic) deployment this is no problem as we require only a single AssertionConsumerService. With the new architecture, each application is able to redirect to the IdP, but the IdP can only redirect to the statically configured ACS. How can each application receive the AuthnResponse, when only a single ACS is possible?
Any ideas?
From SAML-standards point of view this could be achieved with an SAML IdP Proxy. Your apps, acting as the ServiceProviders only communicate with the IdP part of the IdP Proxy. The actual IdP only communiates with the SP apart of the IdP Proxy (so there is only a single ACS url).