Investigate more scalable IAM service options

[benmcclelland]

The internal IAM service is just meant to be a simple IAM service for a handful of local accounts. For a more scalable approach, we would probably want to interface with a more scalable system. We will want to maintain the internal IAM service for the simple cases with no outside dependencies.

Some ideas to investigate:
Redis cluster
etcd
keycloak
okta

We will want to make this modular as well, so that we can implement more of these as different sites have different needs. Part of this investigation will determine if the current IAM interface is sufficient for all of the implementations:

// IAMService is the interface for all IAM service implementations
type IAMService interface {
	CreateAccount(access string, account Account) error
	GetUserAccount(access string) (Account, error)
	DeleteUserAccount(access string) error
	ListUserAccounts() ([]Account, error)
}

The important one to implement would be GetUserAccount, where the others are only needed if we want to manage users through the versitygw admin API.

[benmcclelland]

we can open tickets for specific iam services as requested