Discussion:
'relying party' error
David Bantz
2014-08-26 18:13:03 UTC
Permalink
Error Message: SAML 2 SSO profile is not configured for relying party https://uaacommons2.wpengine.com
The entity ID we are using in apache is urn:mace:uncommon:alaska.edu. Is this correct for your test? Please advise. Thank you.
1) The entity in the Error Message is the vendor’s entityID as per the metadata provided me.
What would trigger the SP to request relying party configuration for itself?

2) the entityID of my IdP is urn:mace:incommon:alaska.edu but apart from the amusing typo,
why would Apache on the service side need my IdP’s entityID?

3) The first attempt of the vendor to provide their SP metadata at http://vendor-server/Shibboleth.sso/Metadata
mysteriously had the entityID of my IdP. That particular problem has been corrected by the vendor at my insistence,
but I wonder if there could be some systematic confusion of IdP and SP on their part.

David Bantz
UAlaska
Cantor, Scott
2014-08-26 18:43:11 UTC
Permalink
I¹m integrating my IdP with a vendor¹s Shibboleth SP. I¹m puzzled by the
You're just confused because he's wrong. That's your IdP throwing the
usual "I have no metadata for the SP" error. He's not receiving anything
from you by that point.
1) The entity in the Error Message is the vendor¹s entityID as per the
metadata provided me.
What would trigger the SP to request relying party configuration for itself?
Nothing, because that isn't the issue.
2) the entityID of my IdP is urn:mace:incommon:alaska.edu but apart from the amusing typo,
why would Apache on the service side need my IdP¹s entityID?
To avoid discovery, you give it the IdP to use.
3) The first attempt of the vendor to provide their SP metadata at
http://vendor-server/Shibboleth.sso/Metadata
mysteriously had the entityID of my IdP. That particular problem has
been corrected by the vendor at my insistence, but I wonder if there
could be some systematic confusion of IdP and SP on their part.
At some point clearly, but that's not the cause here unless the metadata
you loaded still has the broken entityID in it. In any case, what you have
doesn't match the entityID he's using.

-- Scott
--
To unsubscribe from this list send an email to users-***@shibboleth.net
David Bantz
2014-08-26 19:14:26 UTC
Permalink
Post by Cantor, Scott
I¹m integrating my IdP with a vendor¹s Shibboleth SP. I¹m puzzled by the
You're just confused because he's wrong. That's your IdP throwing the
usual "I have no metadata for the SP" error. He's not receiving anything
from you by that point.
Ah yes, he didn’t believe or understand my statement that only my DEV/TEST IdP
was configured. Yes, he used the production IdP which doesn’t have the SP metadata
and got “the usual."
(The DEV/TEST IdP does have metadata and responds with good SAML assertion,
which I had dutifully copied before encryption and provided the vendor.)
Post by Cantor, Scott
2) the entityID of my IdP is urn:mace:incommon:alaska.edu but apart from
the amusing typo,
why would Apache on the service side need my IdP¹s entityID?
To avoid discovery, you give it the IdP to use.
Apache, in addition to or instead of SP’s shibboleth2.xml for which I gave them
exact snippet to consume my IdP metadata?

Further communication from vendor indicates they have the following Apache config snippet:
<Location />
ShibRequestSetting applicationId urn:mace:incommon:alaska.edu
</Location>
Isn’t that supposed to be the name of the vendor’s service instead of my IdP?
(and in any case bad syntax isn’t it? - how could that possibly work?)
Cantor, Scott
2014-08-26 19:38:05 UTC
Permalink
Apache, in addition to or instead of SP¹s shibboleth2.xml for which I
gave them
exact snippet to consume my IdP metadata?
Depends on the use case.
<Location
/>
ShibRequestSetting
applicationId urn:mace:incommon:alaska.edu
</Location>
Isn¹t that supposed to be the name of the vendor¹s service instead of my
IdP?
(and in any case bad syntax isn¹t it? - how could that possibly work?)
The setting for controlling the entityID content setting is not
surprisingly called entityID. ApplicationIds are anything you want them to
be, they just have to match the ApplicationOverride settings used. Setting
an applicationId to the name of an IdP is not really very sensible because
it's a really bad idea to use an override for every individual IdP. That's
not how the SP is meant to be used.

-- Scott
--
To unsubscribe from this list send an email to users-***@shibboleth.net
Loading...