Remote authenticator and authorizer #234
Conversation
moroten
force-pushed
the
remote-auth
branch
3 times, most recently
from
8e43646 to
47d3807
Compare
|
@EdSchouten Welcome back from Christmas holiday. I forgot to bring this up for discussion yesterday. Any comments? No hurry, take your time. |
Prepare for remote authentication and authorization to avoid future curcular dependency.
|
I've now rebased and fixed all the review comments. The changes were done in |
|
@EdSchouten friendly ping. Would you like me to click "Resolve conversation"? |
| "google.golang.org/grpc/status" | ||
| ) | ||
|
|
||
| type remoteRequestAuthenticator struct { |
There was a problem hiding this comment.
What are your thoughts on calling this requestHeadersAuthenticator as well? Yes, it would be the same name as the underlying interface, but because it's in a different package (auth.RequestHeaderAuthenticator vs. http.NewRequestHeadersAuthenticator()) they would still be sufficiently distinct.
The reason I'm bringing this up is because there isn't really anything "remote" about this type. It would be perfectly fine to have an implementation of auth.RequestHeadersAuthenticator that looks at stuff in a SQLite database.
This also makes me wonder: should we reimplement our JWT auth to be built on top of this interface as well?
There was a problem hiding this comment.
This also makes me wonder: should we reimplement our JWT auth to be built on top of this interface as well?
Is that just to extract a single header into the JWT handler? Maybe I didn't get how you meant.
There was a problem hiding this comment.
Right now we have these:
-rw-r--r-- 1 ed staff 1240 Dec 15 10:38 pkg/grpc/jwt_authenticator.go
-rw-r--r-- 1 ed staff 1048 Dec 15 10:38 pkg/http/jwt_authenticator.go
But considering that we now have pkg/{grpc,http}/request_header_authenticator.go, we no longer need these, right? We could throw them away and provide a single implementation of auth.RequestHeadersAuthenticator that does the same thing.
There was a problem hiding this comment.
Now, I get it. I've pushed an update which I've verified in bb-deployments docker-compose for the gRPC header handling.
The authenticate and authorize tasks can now be sent remotely over gRPC to an external service. This way, custom authentication and authorization does not require a modified builds of the Buildbarn components. To avoid spamming the remote service with calls for every REv2 request and keep the latency low, the verdicts, both allow and deny, are cached for a duration specified in the response from the remote service.
The authenticate and authorize tasks can now be sent remotely over gRPC to an external service. This way, custom authentication and authorization does not require a modified builds of the Buildbarn components.
To avoid spamming the remote service with calls for every REv2 request and keep the latency low, the verdicts, both allow and deny, are cached for a duration specified in the response from the remote service.