Client Certificate is requested about lite-idp HOT 8 CLOSED

I'm going to close this issue. @reluxa, If you don't want artifact binding for your use case, you can change the TLS configuration of the IdP by setting the TLSConfig property on the IdP. I realize it means creating your own binary, but I don't want to allow it via configuration change because of the side effects.

from lite-idp.

I agree. However, my primary use case is artifact binding. In that flow, I authenticate service providers by their certificate rather than verifying XML signatures on the requests. I don't think go allows you to prompt for a certificate on one path but not others, but I could be wrong. I'll revisit this and see if I can up come with a solution. I'm open to suggestions.

from lite-idp.

One approach you can take is by manually verifying that there is a certificate on whichever paths require a certificate. i.e. (pulled from a handler I wrote for testing this same problem):

if len(r.TLS.PeerCertificates) == 0 {
	http.Error(w, "No certificate provided with request", 403)
	log.Debugf("Request with no authorization info or certificate failed authentication")
	return
}

It's far from ideal, and I honestly can't say I'd advocate for that to be added in this project, but @reluxa could fork and take a similar approach.

EDIT: This would be paired with the VerifyClientCertIfGiven config as mentioned in the issue. The whole thing could likely be conditionalized with a handler that only does that check wrapped around in cases where it's desired.

from lite-idp.

That's what's happening here.

Clients are always prompted for a certificate, but it's the only path that requires them. However, clients don't include certificates in the request if we don't at a minimum request them.

from lite-idp.

Oh, with that said - the suggested suggested client auth configuration ought to behave appropriately. VerifyClientCertIfGiven is a bit misleading, in that it does request a certificate (https://golang.org/pkg/crypto/tls/#ClientAuthType), and verifies it if it's given.

from lite-idp.

And that said, I saw some odd behavior with that client auth configuration in firefox. I didn't dig around too much in there to understand what was going on, and I can't remember whether or not I verified the behavior on other client auth configs. That's not terribly helpful, but something to potentially be wary of.

from lite-idp.

The "suggested" client auth configuration is the current configuration,

from lite-idp.

Whew, I had this issue totally backwards in my head. Thanks for clearing that up and sorry for the confusion.

from lite-idp.