0

I've been reading through the various ways to configure an IdP/SP relationship and going back forth with a vendor I'm setting up our IdP to authenticate with. We've exchanged metadata and the essentials like Entity ID and login URL's, but when I go to test at the login page it fails because it can't resolve our IdP URL. As I understand it, the SP should be sending my browser a redirect to the IdP and doesn't need to access it directly.

My questions are around that understanding:

  • Is it correct that as an IdP, I should be able to setup SSO as SP-Initiated, with Redirect or Post methods, without the IdP being available to the SP?
  • If that's true, is there something I should be asking the vendor or SP to look at on their end in order for the redirection to take place without checking for my IdP URL?
  • If it's not the case, is there another SAML method allowing for SSO to work without exposing the IdP to the internet?
ceskib
  • 761
  • 1
  • 9
  • 24

1 Answers1

1

  1. The most commonly used SAML bindings for sending the SAML authn request to the IdP are HTTP-Redirect and HTTP-Post. Both of these involve the authn request being sent via the browser. There's no direct site to site communication. If a user can browse to your IdP's single sign-on service URL, the SP should be able to send the authn request.

  2. I'm not sure what the SP considers to be a valid URL. Presumably this URL was specified in your IdP metadata. Perhaps they have additional constraints above and beyond this. You would need to ask them for further details and whether any constraints they impose could be relaxed.

  3. The IdP has to be accessible to the browser. If users are on some intranet, as long as they can browse to the IdP's URL they should be able to SSO.

ComponentSpace
  • 111
  • 2