A common SAML use case is where authentication is federated by an identity provider of more than one issuer.
It would be nice for Spring Security to simplify this. There are already a number of tickets in place to achieve this; they are aggregated here:
- [x] #12848
- [x] #12841
- [x] #12842
- [x] #12847
- [x] #12846
- [x] #12844
- [x] #11828
- [x] #10243
- [x] #12843
- [x] #12845
- [x] #12880
- [x] Consider Spring Boot properties that use
RelyingPartyRegistrations#collectionFromMetadataLocation
Comment From: stnor
Great. Perhaps you can look through this SAML WebSSO Technology Profile V1.0.0.pdf for some more things to consider?
Thanks.
Comment From: OrangeDog
~The linked tickets all seem to be for the opposite case. The relying party is the service provider, not the identity provider. These tickets are all about having multiple relying parties, not multiple asserting parties.~
Edit: RelyingPartyRegistration is a pair of a relying and an asserting party, so this all looks good.
Comment From: jzheaux
While some are loosely related, these tickets are what was needed to support multiple asserting parties from one provider. I think the confusion comes from the fact that a RelyingPartyRegistration is an object that contains a single RP/AP pairing, meaning that once you introduce multiple asserting parties, you get multiple RelyingPartyRegistrations with the same relying party entity id.
Comment From: coffeebeantraining
Hello, I have a workload use case where we have x number of Java Web apps as war files and the source code is not available, however, we need to setup either a Tomcat or TomEE container to act as the Service Provider and I was hoping I could just use the spring-security-saml2-service-provider jar as referenced here: https://mvnrepository.com/artifact/org.springframework.security/spring-security-saml2-service-provider. The IDP will MSFT Entra ID non-gallery enterprise app with SAML enabled.
Would you and anyone happen to know if this is possible? Thanks for any suggestions.
Comment From: jzheaux
Hi, @coffeebeantraining! The best place for this question is StackOverflow, which we monitor regularly for questions like that one. If you've already asked there, feel free to paste your link here for increased visibility.
The short answer to your question is Spring Security is designed to run within any standard servlet container. If you are planning on using Tomcat, you might consider Spring Boot, which embeds Tomcat and simplifies configuration and deployment a great deal.
Comment From: coffeebeantraining
Hi, @coffeebeantraining! The best place for this question is StackOverflow, which we monitor regularly for questions like that one. If you've already asked there, feel free to paste your link here for increased visibility.
The short answer to your question is Spring Security is designed to run within any standard servlet container. If you are planning on using Tomcat, you might consider Spring Boot, which embeds Tomcat and simplifies configuration and deployment a great deal.
@jzheaux Thank you for reply. In our situation we need to be able to use the container, either Tomcat or TomEE as the container and just include the plugin jar or extension and be able to configure it to act as the Service Provider. I'm not sure how that work work with Spring Boot and embedding tomcat. We're not looking to build any apps, but rather migrate existing apps (war files) without access to source code and be able to integrate with MSFT Entra ID SAML. I did get a proof of concept working with Apache Fediz Tomcat plugin, but that was compiled with JDK8 so it doesn't work in our situation because we're using TomEE as the container with JDK21 and I believe Fediz is using javax whereas TomEE uses Jarkarta.
Comment From: coffeebeantraining
Hi, @coffeebeantraining! The best place for this question is StackOverflow, which we monitor regularly for questions like that one. If you've already asked there, feel free to paste your link here for increased visibility.
The short answer to your question is Spring Security is designed to run within any standard servlet container. If you are planning on using Tomcat, you might consider Spring Boot, which embeds Tomcat and simplifies configuration and deployment a great deal.
Posted a question on Stack Overflow and hoping someone can provide some insight, Thanks, https://stackoverflow.com/questions/78044632/how-to-configure-spring-security-saml2-service-provider-with-tomcat-or-tomee-for
Comment From: OrangeDog
Another major item missing compared to the old extension (and which OpenSAML also provides implementation for) is external discovery.
That is, rather than the application implementing the choice of asserting party itself, it redirects to an external service that's part of the federation - https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf
Spring's /saml2/authenticate/{registrationId} does not follow that protocol, and indeed cannot be used with entity ids at all (#15017).