Testing SAML2 Support

Fri Aug 7 09:19:56 EDT 2015

On Fri, 2015-08-07 at 04:22 +0000, Cantor, Scott wrote:

I assumed it did. It should.

Not in my case, though I admittedly could have something configured wrong. I just see the same exact line twice before the more revealing message about lacking the protocol support. I should probably note this is from idp-process.log, perhaps I'm looking in the wrong place?

I would assume so. If that's the one you're talking about, that would throw the unregistered error.

Good to know, in that case we can't drop SAML 1 support at this time, since that app happens to be one of our most used ones internally.

That in mind, my original plan had been to remove SAML1 and place in SAML2. Is it out of the question to simply add the remaining SAML2 portions to our published metadata while leaving all SAML1 support in place? Most vendors have worked with SAML2 using this form of testing, and the only 2 that have completely bombed out have either not supported SAML2 at all or have another obscure error. (The latter of which I've initiated contact with the vendor about.) It seems like with the latter case solved, that the ones requiring SAML1 will just continue to work provided all that support is retained, assuming I have the correct idea here?

I can't really put myself in the shoes of somebody that doesn't have a fairly deep insight into what the problem is already. When I did this, I generally knew roughly what they had screwed up and I was basically telling them what to fix.

I wasn't 100% right. A couple of cases turned out to legitmately be casued by cookie issues that essentially meant I couldn't do IdP-initiated SSO and so there was no way to test it.

In the absence of that experience, it's not going to be an easy road to get them to understand there might be a problem, but if all you have to go on is some generic error, that's about all you can do.

If the SP is Shibboleth, there's a decent chance I can guess what it's doing wrong if that's what you're running into. But mostly the issues are with cross-protocol attribute mapping in pretty much any implementation.

Hmm, so it seems like there's a legitimate chance that you can only go so far with testing, some of it will just need to be attempted in a production capacity?

That said it seems that most of these SPs are Shibboleth, so hopefully they'll be open to suggestions of fixes.

I ran into one that refused to support mappings of both protocols at the same time and required a flag day to change. I reported the problem to my customer and let them either pressure the vendor or live with an outage when the time came.

Hmm, sounds somewhat familiar unfortunately. We have an SP, that shall remain nameless, that has been pushing our organization to pay an hourly rate to have someone even look at logs to see what's causing the double login issue that I had previously mentioned on here. I hope other SPs prove a bit more cooperative.

-- Brandon McKean IT / Systems Linux Administrator (540)568-4235
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150807/af452586/attachment-0001.html>