Shibboleth Developers

["Scott Cantor" <>]

> I've tried both, but without success.
> It seems that if there's only and ADFS initiatior it gets ignored when a
> new session is required.

All I can see so far is that using them outside of a Chaining initiator
causes problems with the error handling. That's no matter which type you
use. I get the same spurious error with any of them if there's metadata, but
no role. I tried ADFS and SAML2, same error. It's caused by the handler not
throwing an actual exception but just returning nothing, so it falls through
some other logic. That's a significant bug, I'll have to rework some things.

> I've tried to use the same configuration but with type "Shib1" or
> "SAML2", and I got the proper error: "unable to locate SAML
> 2.0/Shibboleth-aware identity provider role for provider".

Maybe in the log, but you cannot be getting that as an exception.

> I've also tried to specify a non-existent entityID: with type "Shib1" or
> "SAML2" I got an "unable to locate metadata for provider" error, with
> "ADFS" I got the same "None of the configured SessionInitiators handled
> the request" (or "No default session initiator found", if I use only an
> ADFS entry).

I get the same error with any type of handler if the entityID is wrong.

I used this:

<SessionInitiator type="ADFS" Location="/Login" id="adfs" isDefault="true"
      relayState="cookie" entityID="bad"/>

I get the metadata error as expected. Granted that's with the trunk,
although I don't think that's changed at all since the last beta.

The problem case is when the entityID is ok but the role is missing, then it
doesn't handle things reasonably unless it's chained. But even then you'd
only get the "nothing handled this request" error.

The system can't do much in these cases, it's designed to either work or
delegate to a discovery handler. If it falls through, nothing good can
happen. It's only a question of how bad it is.

-- Scott