Skip to content

Just my thoughts... #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
daniel-ac-martin wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Just my thoughts... #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 3 additions & 6 deletions README.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ Mutual TLS means that connecting clients need to have a client certificate befor
|Client certificates will expire, and hence need to recreate these for all clients periodically, which introduces a lot of overhead and potential for errors

|
|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?)

@daniel-ac-martin daniel-ac-martin Nov 15, 2016

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@daniel-ac-martin daniel-ac-martin Nov 15, 2016

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

@daniel-ac-martin daniel-ac-martin Nov 15, 2016

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

|===

=== OAuth2 with keycloak
Expand Down Expand Up @@ -51,11 +51,8 @@ Basic HTTP auth requires a username and password to be sent with every request.
.Pros and Cons of Basic HTTP Auth
|===
|Pros | Cons
|Very simple to set up initially
|Doing anything beyond basic auth is difficult

|
|User accounts have to be managed by your application, introducing complexity
|Simple
|Simple
|===

== Acceptance tests, documentation, and creating a mock of your API

@daniel-ac-martin daniel-ac-martin Nov 15, 2016 •
edited
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Expand Down