1

I implemented an SP using Spring SAML. I tested it with the SSO Cicle IDP. I have now Web SSO working fine. My customer is using Tivoli Federated Identity Manager as his IDP.

My question is, is having my SP working with one IDP(SSO Circle) considered sufficient to start the integration phase with the customer? Is the Web SSO process independent of which IDP is used(since SAML is a protocol in the end) with my SP?

Thanks in advance.

Omar Azzam
  • 114
  • 2
  • 8

2 Answers2

3

Yes - SAML is a protocol so (in theory) that fact that you have got it working with one IDP means that it should work for others.

But you need to take into account that the options may be different e.g. one IDP may have encrypted tokens and the other not or one may enforce having AuthnRequests signed whereas the other may not care.

rbrayb
  • 46,440
  • 34
  • 114
  • 174
  • 2
    Agreed SAML is a standard, but a very flexible one. In the standard many attributes are optional, but in some implementations they are required and in others they are still optional. – Stefan Rasmusson Nov 06 '14 at 18:34
1

In my experience, you may encounter issues with the SP metadata that the spring-saml extension helps generate. For example I develop using OpenSSO and whenever I move code to higher environments (which uses a different IDP) I always have trouble with entityIDs which are in URL form. Thankfully most IDPs will allow you to edit the metadata while importing. So I think you should be fine, and if you do face issues, I would first look at the SP metadata.

Arunabha Mukhopadhyay
  • 13
  • 3
  • You can of course configure explicit entityID during metadata generation in Spring SAML. The default entity ID is a URL which should be allowed by all IDPs. Previous Spring SAML versions had a bug in default generation of ID in metadata (not entityID) which could include invalid characters. This has been fixed in Spring SAML 1.0.0.RELEASE – Vladimír Schäfer Nov 13 '14 at 09:15