Just my thoughts... - #4
Conversation
Probably shouldn't actually merge this.
|
|
||
| | | ||
| |Have to maintain a CA for signing client certs | ||
| |Have to maintain a CA for signing client certs. (Have you thought about how you will revoke access should this need arise?) |
There was a problem hiding this comment.
This is possibly using CRLs (Certificate Revocation Lists). How we manage the updating and distribution of these lists is left as an exercise for the reader.
There was a problem hiding this comment.
For internal communication I have a reasonably nice solution in LEV using long-lived, self-signed certs.
There's not too much benefit over standard TLS plus basic auth, except that the auth happens outside of HTTP. (It's possibly you would want to use basic auth for something else.)
Any I would like to get people's thoughts on it...
There was a problem hiding this comment.
When I say self-signed, I suppose what I'm getting at is that I'm pretty much side-stepping all the complexity that comes with running a CA.
Also, for internal stuff there /might/ already be better solutions out there using cfssl which is what is usually used with k8 I believe. I'd defer to the devops guys on that one.
| |Doing anything beyond basic auth is difficult | ||
|
|
||
| | | ||
| |User accounts have to be managed by your application, introducing complexity |
There was a problem hiding this comment.
This isn't really true. We can manage the user accounts anyway we like. It would be perfectly possible to have SSO using basic auth just that we don't have such a solution at the moment.
If nothing else, it would be possibly to write a type of forward signing proxy that abstracts away Keycloak's OAuth2 and exposes basic auth instead. Whether such a thing is a good idea on the other hand...
1 participant
Probably shouldn't actually merge this.