[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    RE: [Shib-Users] Help with Test IdP Strategy
From:       "Scott Cantor" <cantor.2 () osu ! edu>
Date:       2010-04-30 15:00:19
Message-ID: 007501cae875$d9ddcd50$8d9967f0$ () 2 () osu ! edu
[Download RAW message or body]

> Question:  Let me ask this then (and please bear with me because I am
> new)... in the metadata for the IdP I see what looks to be certificate
> information.. is this related to SSl connectivity or SAML.

Either or both, that depends on what you're doing and which versions and
profiles are being used.
 
> The reason that
> I ask is that if the SP attempts to connect to what is listed in the
> entityID it will not be able to reach it, since we have a something
> different on the front of the load balancer.

If you mean that the location of endpoints related to SOAP traffic is going
to be different in test vs. production, and that there would be no way to
indicate which were which in a single entity's metadata, yes, that is true.
That wasn't the terminology you used, so it wasn't the statement I responded
to.

And yes, testing with SOAP is where everything gets drastically more
complex. But it doesn't really matter, because all you have to be able to do
here is prevent breaking your production IdP when you provision new policy.
That doesn't require testing every interaction or scenario with a new SP
before changing *anything*.

It just requires that you have the ability to test locally via your own SPs
or with front-channel flows that provide sufficient confidence that the
worst that might happen is that not everything will work 100% right with the
new SP which isn't supposed to be in production with you anyway.

> So if I do as Chad states and
> give them the metadata to load on their end.. will they not end up not
being
> able to reach my IdP?

Yes, but now you have the same problem in reverse. Why should they be
willing to link your test IdP into their production SP? And why is it their
job?
 
> From Me:  It is working now so I guess SOAP is not an issue.

Personally, I wouldn't guess, but there is no SOAP use when SAML 2 is used
in the default manner with POST and encryption and without logout. The
metadata should reflect what you support. If you don't use SOAP, don't
advertise endpoints with that binding. Then there's no guessing.
 
> From Me:  So are you saying that you advise us to create a test SP and
> somehow mimic what the other SPs are doing in our test env in order to
have
> the changes needed for production?  And this is what everyone else is
doing?

I'm saying that you need to understand and operate SPs and be able to test
the *kinds* of changes involved, not the specific changes that any given SP
might need, particularly at the level of application behavior or that kind
of thing.

You can't test effectively if you have to rely on systems you don't control
to perform the testing.

The changes people make for "a new SP" typically amount to attribute
resolver or filter changes. The resolver can be well-tested without special
effort. Filter changes can be tested by using SPs you control to test a
policy and then modifying the policy for production to reference the real
SPs involved. It's not a big deal.

-- Scott


[prev in list] [next in list] [prev in thread] [next in thread]