open ports / version mismatch

[Peter Schober]

* Nate Klingenstein <ndk at internet2.edu> [2013-06-12 03:26]:
> I guess if I had to grasp at a straw, I'd see if the SP's that the
> IdP is working with successfully are including a desired
> authentication method of
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
> with their requests, as Eric alluded to, while your SP is not
> specifying a desired authentication method in its requests, and the
> IdP has both ph:RemoteUser and ph:UsernamePassword uncommented and
> using the default configuration.
> 
> If my straw is the correct one, the best fix in this case would
> probably be for the IdP to comment out the RemoteUser login handler.

If the RemoteUser handler is active but the endpoint not properly
protected by the IdP that's of course a configuration error, as Nate
and Scott already said. The interesting (to me) bit seems to be what
the IdP could have done to make this error only happen to this SP.

Will setting <rp:DefaultRelyingParty
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
in relying-party.xml achieve that? The the question becomes why the
OP's SP does not fall into this category, i.e., it would suggest the
IdP has created a custom relying party config for this SP which then
fails to default the PasswordProtectedTransport authn method for this
SP, which in turn makes it fall through to "unspecified" which
triggers the (otherwise unused) RemoteUser handler?
(Or maybe DefaultRelyingParty/@defaultAuthenticationMethod is carried
over to RelyingParty/@defaultAuthenticationMethod, then the mechanics
would need to be different.)

Moving this 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
from the <ph:LoginHandler xsi:type="ph:RemoteUser"> to
<ph:LoginHandler xsi:type="ph:UsernamePassword"> in handler.xml should
also take care of that.
(Besides not having a non-functional login handler active.)
-peter