Shibboleth Developers

["Scott Cantor" <>]

> Lets define a federation-less websso community: a site using Shib2 for
> websso wants to interwork with a site using Ping Federate for websso.

Ok, the way you worded it, I thought you meant community as in "people
designing SSO specs that are jointly looking at things like this use case".

> The community is the 2 sites - who have shared peer-peer metadata - and
the 2
> vendors of SAML systems (who presumably want their "customers" to have the
> maximum possible interoperability).

That's fine, I understand you now. You're trying to understand the interop
constraints on IsPassive. All I know is what the specs say, and since the
SP/application boundary is undefined in SAML, but key to how IsPassive
works, I suspect it's going to vary.

> Now, Ping Federate has been tested at the IDP-lite/SP-lite conformance
> targets, and Ill guess that Shib2 would pass those and perhaps more
> stringent conformance targets.

It's a non-overlapping set of stuff we would pass.
 
> But, for its _default_ "authentication provider adaptor", I've yet to find
a
> way to program the authentication provider website co-resident with the
Ping
> Federate IDP to (a) receive the ispassive=true signal on a request, (b)
AND
> THEN induce the required (or indeed any) error to be returned to the
> requestor (when the code that I get to write in the provider finds that it
> cannot satisfy the request).

I'm not sure which piece you can't make work. The SP can generate requests
with IsPassive very easily, and the IdP definitely will respond with an
error if it gets one (see recent google thread).

Which part of Shib are you trying to make work?

> I was thinking of handling the scenario above at the Shib SP, where simply
> no response comes back from the Ping Federate IDP (neither error nor
> positive assertion), and the SP protocol/state machine is (formally)
waiting
> on one. Can a SP [implementation] simulate a "local error" on some time
out,
> for consumption by the application?

No. The SP has no "state machine" across the request/response flow. Each
piece is independent, and the only state it maintains is the RelayState,
which is normally not maintained in server state. So there is no notion that
would match this.

In fact, the SP ignores the InResponseTo value in the SSO message in all
cases. OpenSAML doesn't, but the SP has no Request ID to give to OpenSAML
when it processes the incoming message. It treats all responses as
essentially unsolicited, oddly enough.

-- Scott