On 04/15/2016 06:55 PM, Pedro Igor Silva wrote:
What I tried to say is that ACSI and ProtocolBinding are mutually
exclusive. And usually, ProtocolBinding is used with ACSURL.
And that is why we always recommend POST (and also because the
assertion is not exposed) and the usage of that "Force Post Binding".
Which is enabled by default ...
> 1) Since nothing was specified use a default (HTTP-Post). The
spec
> seems to be silent on what the default should be but HTTP-Post
> seems like the best choice.
See above. We do that. And, AFAIK, we don't support Artifact.
Considering that we don't support Artifact. We would always
choose
POST.
The ACSURL is always checked against the valid URLs you specified in
your client configuration.
We already choose the ACSURL based on the client configuration.
I think the point is, can you live with ProtocolBinding and ACSURL ?
Or do you really need full spec support (ACSI, etc) at this regard ?
It's not a question if I can live with ProtcolBinding and ACSURL, I have
no control over what an SP sends. If a SP sends only an ACSURL Keycloak
needs to perform a POST with the AuthnResponse. You've said multiple
times above that Keycloak will do a POST with the AuthnResponse but
that's not what Keycloak is doing, instead it's causing a GET on the
ACSURL using the HTTP-Redirect binding. So we need to figure out why
Keycloak is not behaving as you believe it should be.
I've attached the protocol exchange with annotations as a text file (so
the mailer won't mangle it). Maybe I've stared at this too long and can
no longer see what's in front of me (a good chance) but it sure looks to
me like Keycloak is behaving differently than expected.
Many thanks in advance for your help Pedro!
--
John