Shibboleth Developers

[Peter Williams <>]

 

Far as I know it sends back the error the SAML specification requires it to

send back.

 

> Is this common practice in the websso profile community?

 

I know of no such community.

 

 

Lets define a federation-less websso community: a site using Shib2 for websso wants to interwork with a site using Ping Federate for websso. 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).

 

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.

 

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).

 

> Is there any writeup anywhere on what motivates Shib SP to handle inbound

> errors the way it does?

 

Displaying them or redirecting to an application to handle them? No, since

offhand I can't think of any other options. Please suggest another.

 

-- Scott

 

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?