Skip to content

feat: add session actor middleware #897

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.

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

Closed
wants to merge 11 commits into from
41 changes: 41 additions & 0 deletions coderd/access/session/actor.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
package session

import (
"github.com/coder/coder/coderd/database"
)

// ActorType is an enum of all types of Actors.
type ActorType string

// ActorTypes.
const (
ActorTypeUser ActorType = "user"
// TODO: Dean - WorkspaceActor and SatelliteActor
)

// Actor represents an unauthenticated or authenticated client accessing the
// API. To check authorization, callers should call pass the Actor into the
// authz package to assert access.
type Actor interface {
// Type is the type of actor as an enum. This method exists rather than
// switching on `actor.(type)` because doing a type switch is ~63% slower
// according to a benchmark that Dean made. This performance difference adds
// up over time because we will call this method on most requests.
Type() ActorType
// ID is the unique ID of the actor for logging purposes.
ID() string
// Name is a friendly, but consistent, name for the actor for logging
// purposes. E.g. "deansheather"
Name() string
Comment on lines +25 to +29
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't this either be system or the user's name? Seems like certain routes should never be system, so I'm confused when the logging would come into play.

Copy link
Member Author

Choose a reason for hiding this comment

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

On each request I want to log the actor name at least, so it's easy to see which user made a request in the logs. I am removing the SystemActor though.

Copy link
Member Author

Choose a reason for hiding this comment

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

is this ok @kylecarbs? The goal of this is so we can log the username without having to do a type cast because of the same reason as above (type switching just to read the username is very slow).

Copy link
Member

Choose a reason for hiding this comment

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

If we're just going to have the UserActor do we need to generalize the actor type at all? Could we just use database.User directly? That way we wouldn't have to type-cast at all.

Copy link
Member Author

Choose a reason for hiding this comment

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

We're not just going to have the UserActor type. We will also have a WorkspaceActor and eventually a SatelliteActor.

Copy link
Member

Choose a reason for hiding this comment

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

If we just have two or three though, could we just log the username / workspace / satellite name separately? If the actor type is primarily going to be used for that, I'm hesitant to say it's worth the grouping.

I'd think we'd have separate routes for users / workspaces / satellites anyways, similar to how agents can only access specific routes right now. In that pattern, there's no opportunity to have a user call an agent route, because they'll never need to do so.

Copy link
Member

Choose a reason for hiding this comment

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

That is one way to separate things. But that makes each actor type more distinct.

RBAC means an agent token is just a UserActor with a reduced scope. I see the benefit in having 1 type and letting rbac decide what they can and can't do.

I see value in the separating routes approach too.

Both options require their own care. One thing I wonder about is will a provisionerd ever need to query coderd for anything? Like is there a case some provisionerd will want a system_user with some RBAC role/perms to query some extra endpoints? I have no idea if there is, but having 1 system is nice in the sense all actors are equivalent and just defer to rbac for drawing lines.


// TODO: Steven - RBAC methods
}

// UserActor represents an authenticated user actor. Any consumers that wish to
// check if the actor is a user (and access user fields such as User.ID) can
// do a checked type cast from Actor to UserActor.
type UserActor interface {
Actor
User() *database.User
APIKey() *database.APIKey
}
7 changes: 7 additions & 0 deletions coderd/access/session/doc.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
// Package session provides session authentication via middleware for the Coder
// HTTP API. It also exposes the Actor type, which is the intermediary layer
// between identity and RBAC authorization.
//
// The Actor types exposed by this package are consumed by the authz packages to
// determine if a request is authorized to perform an API action.
package session
49 changes: 49 additions & 0 deletions coderd/access/session/mw.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
package session

import (
"context"
"net/http"

"github.com/coder/coder/coderd/database"
)

type actorContextKey struct{}

// APIKey returns the API key from the ExtractAPIKey handler. The returned Actor
// may be nil if the request was unauthenticated.
//
// Depends on ExtractActor middleware.
func RequestActor(r *http.Request) Actor {
actor, ok := r.Context().Value(actorContextKey{}).(Actor)
if !ok {
return nil
}
return actor
}

// ExtractActor determines the Actor from the request. It will try to get the
// following actors in order:
// 1. UserActor
// 2. AnonymousActor
func ExtractActor(db database.Store) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {
var (
ctx = r.Context()
act Actor
)

// Try to get a UserActor.
act, ok := UserActorFromRequest(ctx, db, rw, r)
if !ok {
return
}

// TODO: Dean - WorkspaceActor, SatelliteActor etc.

ctx = context.WithValue(ctx, actorContextKey{}, act)
next.ServeHTTP(rw, r.WithContext(ctx))
return
})
}
}
124 changes: 124 additions & 0 deletions coderd/access/session/mw_internal_test.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,124 @@
package session

import (
"net/http"
"net/http/httptest"
"sync/atomic"
"testing"
"time"

"github.com/stretchr/testify/require"

"github.com/coder/coder/coderd/database/databasefake"
"github.com/coder/coder/coderd/httpapi"
Comment on lines +10 to +13
Copy link
Member

Choose a reason for hiding this comment

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

Just curious, are we still splitting coder and other github imports?

)

func TestMiddleware(t *testing.T) {
t.Parallel()

successHandler := http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {
// Only called if the API key passes through the handler.
httpapi.Write(rw, http.StatusOK, httpapi.Response{
Message: "it worked!",
})
})

t.Run("UserActor", func(t *testing.T) {
t.Parallel()

t.Run("Error", func(t *testing.T) {
t.Parallel()
var (
db = databasefake.New()
r = httptest.NewRequest("GET", "/", nil)
rw = httptest.NewRecorder()
)
r.AddCookie(&http.Cookie{
Name: AuthCookie,
Value: "invalid-api-key",
})

ExtractActor(db)(successHandler).ServeHTTP(rw, r)
res := rw.Result()
defer res.Body.Close()
require.Equal(t, http.StatusUnauthorized, res.StatusCode)
})

t.Run("OK", func(t *testing.T) {
t.Parallel()
var (
db = databasefake.New()
u = newUser(t, db)
_, token = newAPIKey(t, db, u, time.Time{}, time.Time{})
r = httptest.NewRequest("GET", "/", nil)
rw = httptest.NewRecorder()
)
r.AddCookie(&http.Cookie{
Name: AuthCookie,
Value: token,
})

var (
called int64
handler = http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {
atomic.AddInt64(&called, 1)

// Double check the UserActor.
act := RequestActor(r)
require.NotNil(t, act)
require.Equal(t, ActorTypeUser, act.Type())
require.Equal(t, u.ID.String(), act.ID())
require.Equal(t, u.Username, act.Name())

userActor, ok := act.(UserActor)
require.True(t, ok)
require.Equal(t, u, *userActor.User())

httpapi.Write(rw, http.StatusOK, httpapi.Response{
Message: "success",
})
})
)

ExtractActor(db)(handler).ServeHTTP(rw, r)
res := rw.Result()
defer res.Body.Close()
require.Equal(t, http.StatusOK, res.StatusCode)

require.EqualValues(t, 1, called)
})
})

t.Run("Fallthrough", func(t *testing.T) {
t.Parallel()

var (
db = databasefake.New()
r = httptest.NewRequest("GET", "/", nil)
rw = httptest.NewRecorder()
)

var (
called int64
handler = http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {
atomic.AddInt64(&called, 1)

// Actor should be nil.
act := RequestActor(r)
require.Nil(t, act)

httpapi.Write(rw, http.StatusOK, httpapi.Response{
Message: "success",
})
})
)

// No auth provided.
ExtractActor(db)(handler).ServeHTTP(rw, r)
res := rw.Result()
defer res.Body.Close()
require.Equal(t, http.StatusOK, res.StatusCode)

require.EqualValues(t, 1, called)
})
}
174 changes: 174 additions & 0 deletions coderd/access/session/user.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,174 @@
package session

import (
"context"
"crypto/sha256"
"crypto/subtle"
"database/sql"
"fmt"
"net/http"
"strings"
"time"

"golang.org/x/xerrors"

"github.com/coder/coder/coderd/database"
"github.com/coder/coder/coderd/httpapi"
)

const (
// AuthCookie represents the name of the cookie the API key is stored in.
AuthCookie = "session_token"

// nolint:gosec // this is not a credential
apiKeyInvalidMessage = "API key is invalid"
apiKeyLifetime = 24 * time.Hour
)

type userActor struct {
user database.User
apiKey database.APIKey
}

var _ UserActor = &userActor{}

func NewUserActor(u database.User, apiKey database.APIKey) UserActor {
return &userActor{
user: u,
apiKey: apiKey,
}
}

func (*userActor) Type() ActorType {
return ActorTypeUser
}

func (ua *userActor) ID() string {
return ua.user.ID.String()
}

func (ua *userActor) Name() string {
return ua.user.Username
}

func (ua *userActor) User() *database.User {
return &ua.user
}

func (ua *userActor) APIKey() *database.APIKey {
return &ua.apiKey
}

// UserActorFromRequest tries to get a UserActor from the API key supplied in
// the request cookies. If the cookie doesn't exist, nil is returned. If there
Copy link
Member

Choose a reason for hiding this comment

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

Just a note in the future we need to also support a custom Header for cli auth. Cookie auth will need to do CSRF in future.

// was an error that was responded to, false is returned.
//
// You should probably be calling session.ExtractActor as a middleware, or
// session.RequestActor instead.
Comment on lines +66 to +67
Copy link
Member

Choose a reason for hiding this comment

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

If this is true, could we keep this function private?

Copy link
Member Author

Choose a reason for hiding this comment

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

No because then the linter got mad at me for having the tests be package session, and I have test helpers shared between the user tests and the middleware tests :(

Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't testing the middleware test this function in that case? That's how it works in httpmw right now too.

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to write tests for this function by itself instead of having a giant test file for the middleware when the middleware itself is very small.

Copy link
Member

Choose a reason for hiding this comment

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

Our tests may be deceiving to a caller if they primarily test and exposed a function we don't recommend they use. The middleware is only valuable if it calls this other function, so I'd be hesitant to say the middleware's expectations are small.

That's not to say decomposition isn't right for this case, but I do think our tests should primarily test the primary functions we expose.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll do the internal tests for the entire package in that case then

Copy link
Member Author

Choose a reason for hiding this comment

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

is this ok? @kylecarbs

Copy link
Member

Choose a reason for hiding this comment

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

I think it's best to test the HTTP handler that's being exposed to the API; not being able to test that handler will likely result in a similar experience for callers. Is there a reason we can't test the handler with similar levels of functionality?

Copy link
Member Author

Choose a reason for hiding this comment

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

The middleware handler is tested to handle all possible output states from the user actor function. The user actor tests additionally also test each possible failure state individually.

Copy link
Member

Choose a reason for hiding this comment

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

@kylecarbs I disagree that we should only test a package api imo.

I am all for testing individual functions in a package. I understand unit tests can help api design, and those tests should still exist in the xxxx_test.go file. But having internal tests to test more granular functions is a great way to test edge cases without excess state.

If the internal test fails, that is way more information for debugging than if an api level function that hides the internal functions fails.


So I think internal tests are great. But should not replace package_test functions that better test pkg api design

func UserActorFromRequest(ctx context.Context, db database.Store, rw http.ResponseWriter, r *http.Request) (UserActor, bool) {
cookie, err := r.Cookie(AuthCookie)
if err != nil || cookie.Value == "" {
// No cookie provided, return true so any actor handlers further down
// the chain can make their attempt.
return nil, true
}

// TODO: Dean - workspace agent token auth should not share the same cookie
// name as regular auth
if strings.Count(cookie.Value, "-") == 4 {
// Skip anything that looks like a UUID for now.
return nil, true
}

keyID, _, hashedSecret, err := parseAPIKey(cookie.Value)
if err != nil {
httpapi.Write(rw, http.StatusUnauthorized, httpapi.Response{
Message: fmt.Sprintf("invalid API key cookie %q: %v", AuthCookie, err),
})
return nil, false
}

// Get the API key from the database.
key, err := db.GetAPIKeyByID(ctx, keyID)
if xerrors.Is(err, sql.ErrNoRows) {
httpapi.Write(rw, http.StatusUnauthorized, httpapi.Response{
Message: apiKeyInvalidMessage,
})
return nil, false
}
if err != nil {
httpapi.Write(rw, http.StatusInternalServerError, httpapi.Response{
Message: fmt.Sprintf("get API key by id: %s", err.Error()),
})
return nil, false
}

// Checking to see if the secret is valid.
if subtle.ConstantTimeCompare(key.HashedSecret, hashedSecret[:]) != 1 {
httpapi.Write(rw, http.StatusUnauthorized, httpapi.Response{
Message: apiKeyInvalidMessage,
})
return nil, false
}

// Check if the key has expired.
now := database.Now()
if key.ExpiresAt.Before(now) {
httpapi.Write(rw, http.StatusUnauthorized, httpapi.Response{
Message: apiKeyInvalidMessage,
})
return nil, false
}

// TODO: Dean - check if the corresponding OIDC or OAuth token has expired
// once OIDC is implemented

// Only update LastUsed and key expiry once an hour to prevent database
// spam.
if now.Sub(key.LastUsed) > time.Hour || key.ExpiresAt.Sub(now) <= apiKeyLifetime-time.Hour {
err := db.UpdateAPIKeyByID(ctx, database.UpdateAPIKeyByIDParams{
ID: key.ID,
ExpiresAt: now.Add(apiKeyLifetime),
LastUsed: now,
OIDCAccessToken: key.OIDCAccessToken,
OIDCRefreshToken: key.OIDCRefreshToken,
OIDCExpiry: key.OIDCExpiry,
})
if err != nil {
httpapi.Write(rw, http.StatusInternalServerError, httpapi.Response{
Message: fmt.Sprintf("could not refresh API key: %s", err.Error()),
})
return nil, false
}
}

// Get the associated user.
u, err := db.GetUserByID(ctx, key.UserID)
if err != nil {
httpapi.Write(rw, http.StatusInternalServerError, httpapi.Response{
Message: fmt.Sprintf("could not fetch current user: %s", err.Error()),
})
return nil, false
}

return NewUserActor(u, key), true
}

func parseAPIKey(apiKey string) (id, secret string, hashed []byte, err error) {
Copy link
Member

Choose a reason for hiding this comment

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

Just and example @kylecarbs of a great function to unit test with an easy tabled test. To do this using the middleware would be such a pain because invalid apiKey strings might not even get far enough in the function to get to this parse.

Regardless if the invalid strings reach this in prod, I still think it's of value to know this function works as intended incase it's ever moved/reused.

Copy link
Member

Choose a reason for hiding this comment

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

If this function is well-tested outside of the middleware, it could be argued the middleware doesn't have to be. If both are expected to be well-tested, then tests become duplicative. I'm of the opinion testing the user-expected behavior is much more important than if the code actually works, because the user just wants it to work for them.

Copy link
Member

Choose a reason for hiding this comment

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

The middleware unit test will not test this one function to all of it's edge cases. For one, the middleware does some basic validation above this usage, so any tokens that fall those checks won't make it to parseAPIKey.

The code might be able to be refactored to ensure all keys hit parseAPIKey, but I'm speaking more generally than this one case.

I'm of the opinion testing the user-expected behavior is much more important than if the code actually works, because the user just wants it to work for them.

I don't see how these are not related. These functions are the building blocks, and often they will be reused/adapted by a developer in the future (months out).

I am of the opinion if I write helper functions like this, it's very easy to build a tabled test to confirm my implementation is correct. And if someone comes in later, the tabled tests can often serve better than a comment for what should happen in given cases, because let's be honest sometimes comments are vague/ambiguous. A tabled test does not have this ambiguity. Worse case the tabled test is missing an edge case, in which case the new developer can easily add it.


I do agree if you sufficiently test all the building blocks of a function, then you do not need to test the, in this case, the middle function as exhaustively.

Copy link
Member

Choose a reason for hiding this comment

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

The functions build the API surface, but the most important part of the code is that the API works as expected. I'm not arguing against testing the internals, but we should try to get away with testing via externals first to reduce complexity.

// APIKeys are formatted: ${id}-${secret}. The ID is 10 characters and the
// secret is 22.
parts := strings.Split(apiKey, "-")
if len(parts) != 2 || len(parts[0]) != 10 || len(parts[1]) != 22 {
return "", "", nil, xerrors.New("invalid API key format")
}

// We hash the secret before getting the key from the database to ensure we
// keep this function fixed time.
var (
keyID = parts[0]
keySecret = parts[1]
hashedSecret = sha256.Sum256([]byte(keySecret))
)

return keyID, keySecret, hashedSecret[:], nil
}
Loading