Issues getting PagerDuty which uses SAML 2.0 to talk to Shibboleth IDP.

[Peter Schober]

Charles,

If you want to see that email without your mail system destroying
everything that looks like a URL again, go read it in the archives.
I'm done obfuscating everything in my posts. Details below:

* Cahill, Charles (GE Appliances) <Charles.Cahill at ge.com> [2015-06-11 21:42]:
> Pager Duty also sent me this.  Which they don't seem to be much help
> in getting this configured.

None of this is new. There's one thing of note, though, that may be
the source of that problem (though I told you to try that before,
too):

> Entity ID= "<subdomain>.pagerduty.com"

So they say. I created example metadata for you based on their docs
before, too:
http://shibboleth.net/pipermail/users/2015-June/021824.html
But as I later wrote here (based on empricial data):
http://shibboleth.net/pipermail/users/2015-June/021856.html
that's NOT what PagerDuty named the SAML SP for your account!

The SAML 2.0 authentication request from your account contains:
  <saml:Issuer>https://ge-appliances.pagerduty.com</saml:Issuer>
(Complete authn request attached to this email, for reference.)
So the entiyID of the SP is "https://ge-appliances.pagerduty.com",
not "ge-appliances.pagerduty.com" as stated in their documentation and
the support reply you quote above.

Be that as it may, the only thing relevant for this list and the error
you're still seeing, is that the entityID in the SAML metadata you
have on record for that SP matches what's in the SP's SAML authn
request. So it needs to be the one above (incl the leading "https://",
just like  I wrote 2 weeks earlier).

If you do have set the entityID to that value and the IDP still
doesn't know the SP going by that name, then you're still not loading
that metadata -- or the IDP refuses it, possibly because it's invalid,
or expired.


Also note (but unrelated to your IDP not finding metadata for the SP)
that now the SSO endpoint for your IDP is wrong (I believe it was
right, so you're changing your IDP config on their side, which will
not fix the error that your IDP cannot find metadata for that SP), the
authn request is now HTTP POST-ed to /idp/Authn/UserPassword when it
should be /idp/profile/SAML2/POST/SSO


Finally, in case you or anyone cared how I got to that info and why I
claim to know better than their documentation or support:
https://www.pagerduty.com/ -> login -> Charles' email address ->
https://app.pagerduty.com/accounts/search_results?email=Charles.Cahill%40ge.com&commit=Search
https://ge-appliances.pagerduty.com/?email=Charles.Cahill%40ge.com
select "Sign in with your Identity Provider" at the bottom of the
page, note down the hostname of the IDP (which is currently
fssfedidp3rdprtydev.al.ge.com, it was something else before, either
way it's unreachable for me, so I don't see the HTTP POST to the IDP
in SAML tracer), create an entry in my local resolver to map that
hostname to an existing IP address for any other web server, start
SAML tracer in Mozilla Firefox, try "Sign in" again, pick the SAML
authn request from the HTTP POST to the IDP's endpoint.
-peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ge-app-pagerdury-authnreq.xml
Type: application/xml
Size: 981 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20150612/7fb00a44/attachment-0001.wsdl>