metadata nit pick (was: SSL error with a Shib 2 SP and TestShib-1 IDP

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

metadata nit pick (was: SSL error with a Shib 2 SP and TestShib-1 IDP

Mark K. Miller

On Tue, 16 Jun 2009, Bell D. wrote:

> Federation, InCommon and TestShib. The IDP has been configured with the
> metadata for the Service Provider (I believe through having the metadata
> for the UK Federation loaded).

Yes, this is correct.  I have loaded the full UK Federation metadata file.
However, I'd probably prefer to not do that on my production system.
Sticking with the test system for now, though, I initially made a file out
of the metadata for the SP provided by the Southampton folks here:

http://springboard.soton.ac.uk/Shibboleth.sso/Metadata

Although I didn't notice any errors about metadata being "bad" or not
getting loaded, using the metadata at that URL above would result in erors
being logged about that system 'not being found in my metadata.'
Replacing the file at the URL above, with the one from the UK Federation
site for their metadata resulted in the 'not being found in my metadata'
errors going away.

Is there something the Southampton folks need to do differently to make a
metadata file for their SP?  Is there something I need to do differently
to use the metadata they've already provided?
Reply | Threaded
Open this post in threaded view
|

RE: metadata nit pick (was: SSL error with a Shib 2 SP and TestShib-1 IDP

Cantor, Scott E.
Mark K. Miller wrote on 2009-06-16:
> Although I didn't notice any errors about metadata being "bad" or not
> getting loaded, using the metadata at that URL above would result in erors
> being logged about that system 'not being found in my metadata.'
> Replacing the file at the URL above, with the one from the UK Federation
> site for their metadata resulted in the 'not being found in my metadata'
> errors going away.

Then they're using a different entityID in the two cases, or the metadata
itself is perhaps advertising different protocol support in the two cases.

> Is there something the Southampton folks need to do differently to make a
> metadata file for their SP?

There is absolutely no guarantee that asking the SP to generate metadata
will result in anything sensible for any particular case. It is up to
somebody to eyeball it and ensure it's correct.

That's why I do not advocate pointing an IdP directly at that handler. It
doesn't even generate valid metadata if there are vhosts involved, the ACS
indexes get duplicated.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: metadata nit pick (was: SSL error with a Shib 2 SP and TestShib-1 IDP

Peter Schober
* Scott Cantor <[hidden email]> [2009-06-16 15:54]:

> Mark K. Miller wrote on 2009-06-16:
> > Although I didn't notice any errors about metadata being "bad" or not
> > getting loaded, using the metadata at that URL above would result in erors
> > being logged about that system 'not being found in my metadata.'
> > Replacing the file at the URL above, with the one from the UK Federation
> > site for their metadata resulted in the 'not being found in my metadata'
> > errors going away.
>
> Then they're using a different entityID in the two cases, or the metadata
> itself is perhaps advertising different protocol support in the two
> cases.

From a quick look at the metadata from Metadata handler vs the one
from the UK fed it seems the metadata is roughly much the same. Same
entityId, same keys (except for the Uk-Fed also throwing in the
Globalsign/Cybertrust intermediate CA cert), same ACS URLs.

So from this I'd doubt using the metadata copy from the UK Fed alone
made the observed difference. But that's just my uneducated guess.
-peter
Reply | Threaded
Open this post in threaded view
|

Re: metadata nit pick (was: SSL error with a Shib 2 SP and TestShib-1 IDP

Mark K. Miller

On Tue, 16 Jun 2009, Peter Schober wrote:

> So from this I'd doubt using the metadata copy from the UK Fed alone
> made the observed difference. But that's just my uneducated guess.

So, to test this statement, here's what I just did.  I started by
downloading a fresh copy of whatever is located at the links for the UK
Federation metadata, as well as what's at the link for the springboard SP
metadata.  Then, I copied the fresh UK Federation file to the file name of
the metadata being loaded for these guys, and observed in the logs that
the change was noticed and reloaded.  Then I tried the SP, and the logs
showed this:

2009-06-17 11:33:13,544 DEBUG [IdP] -208753737                          -
Received a request via GET for location
(https://shoepeg.aset.psu.edu/shibboleth-idp/SSO).
2009-06-17 11:33:13,545 DEBUG [IdP] -208753737                          -
Matched handler location:
(https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO).
2009-06-17 11:33:13,545 INFO  [IdP] -208753737                          -
Processing Shibboleth v1.x SSO request.
2009-06-17 11:33:13,545 DEBUG [IdP] -208753737                          -
Remote provider has identified itself as:
(https://springboard.soton.ac.uk/shibboleth).
2009-06-17 11:33:13,545 DEBUG [IdP] -208753737                          -
Provider is a member of group (http://ukfederation.org.uk), but no
matching Relying Party was found.
2009-06-17 11:33:13,545 INFO  [IdP] -208753737                          -
Could not locate Relying Party configuration for
(https://springboard.soton.ac.uk/shibboleth).  Using default Relying
Party: (urn:mace:shibboleth:testshib).
2009-06-17 11:33:13,545 INFO  [IdP] -208753737                          -
Supplied consumer URL validated for this provider.
2009-06-17 11:33:13,547 DEBUG [IdP] -208753737                          -
Using the default name identifier format for this relying party:
(urn:mace:shibboleth:1.0:nameIdentifier
2009-06-17 11:33:13,548 DEBUG [IdP] -208753737                          -
User was authenticated via the default method for this relying party
(urn:oasis:names:tc:SAML:1.0:am:unspecified).
2009-06-17 11:33:13,548 DEBUG [IdP] -208753737                          -
Metadata indicates support for POST profile.
2009-06-17 11:33:13,548 DEBUG [IdP] -208753737                          -
Responding with POST profile

After that, I copied in the metadata from the Southampton folks for the
springboard SP, verified that the change was noticed and loaded, then
tried the SP again.  This time, the logs showed this:

2009-06-17 11:37:07,669 DEBUG [IdP] 58921220                            -
Received a request via GET for location
(https://shoepeg.aset.psu.edu/shibboleth-idp/SSO).
2009-06-17 11:37:07,669 DEBUG [IdP] 58921220                            -
Matched handler location:
(https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO).
2009-06-17 11:37:07,669 INFO  [IdP] 58921220                            -
Processing Shibboleth v1.x SSO request.
2009-06-17 11:37:07,669 DEBUG [IdP] 58921220                            -
Remote provider has identified itself as:
(https://springboard.soton.ac.uk/shibboleth).
2009-06-17 11:37:07,669 INFO  [IdP] 58921220                            -
Could not locate Relying Party configuration for
(https://springboard.soton.ac.uk/shibboleth).  Using default Relying
Party: (urn:mace:shibboleth:testshib).
2009-06-17 11:37:07,669 INFO  [IdP] 58921220                            -
Supplied consumer URL validated for this provider.

Then I made the UK Federation metadata active again and results were like
the first example.