RequestInitiator metadata generated in a case where it shouldn't be

http://svn.shibboleth.net/view/cpp-sp?rev=3692&view=rev

Ok, unchained initiators of only types Shib1, SAML2, and ADFS now generate the metadata. Chains always do on the assumption that the chain is actually something reasonable, and I can't tell in any case.

Well, blocking the various handlers from being installed stand alone is a bit of a mess basically, they don't know enough at creation time to tell. So that's probably why I didn't do it.

So I'll just apply the metadata fix to all of them since they won't successfully run at all, and that kind of implies the endpoint won't really work.

I was originally going to say that my impression was that the spec permits entityID to be omitted, which is true, but I think that it's outside of the spirit of the language to advertise an endpoint that actually breaks on a defined parameter. So I guess I agree, WAYF only shouldn't generate it.

I also can think of some specific cases that would be errors as stand alone handlers, so no reason not to block those, and that also prevents them from generating metadata.

The WAYF case is the outlier because it could stand alone without breaking.

The problem here is that although the entityID parameter is optional and there's specific wording in there to permit the SP to do really anything it likes if it is omitted, it's harder for me to reconcile getting a configuration error out of a session initiator when the entityID parameter is provided.

The expectation I get out of reading the spec is that if there's a request initiator in metadata, I should be able to send a message including entityID and have that work. So, I'd expect the SP not to generate such metadata in cases where it won't, such as this one.

I realise this is probably strictly outside the spec; the issue is that people now have tools (WUGen, in particular) that locate session initiators automatically through metadata and they make the assumption that you can send a message there and have something happen.

I guess it's not clear what we should tell people looking at that metadata if it is possible for the message to result in a "configuration error" message in both the case where entityID is omitted and the case where it's present. What I was naively expecting was that the SP would suppress metadata for a session initiator that couldn't handle entityID because it was "discovery only". An alternative approach would be for the SP to flag this as a configuration error earlier than the time the request arrives, which I don't think it currently does.

Anyway, that was my thinking (sorry for the delay in expanding my original ticket). If this is working as intended, please feel free to resolve appropriately and I'll try to think about alternatives.

I'm not sure, but I think the issue here is something else. That error doesn't mean the handler isn't in place, it should mean that it didn't successfully run. That would be true in that case if entityID were set, since it would dispatch to the WAYF otherwise.

But in terms of metadata, all it knows is that there's a SessionInitiator there, and there is, so I think that's correct.