Open cb372 opened 9 years ago
isn't that what the serviceId is for? Also, is there a point in rejecting clients?
Assuming "API keys" means id-and-shared-secret and using them for authentication (how is TBD), this seems like a reasonable idea.
Advantages that I can think of are:
Wondering if access from insecure clients (JS, Android apps that can't keep secrets) is also going to be considered in this discussion.
More secure
Security was never a concern (as this application was designed to run on a trusted network). If it becomes a requirement, then there are other areas we should be looking into. I think this is a good idea to implement security, although we should think about it a little bit more. Currently exceedingly open areas are :
Forces Octoparts clients to send real identification
It is as real as they want... as they can re-generate their key once in a while. In this sense, it is equivalent to making serviceId
required.
Security was never a concern
Indeed. Maybe it should though. At the moment, once someone gains access to the trusted network (not farfetched), Octoparts makes it trivial to take down an entire set of systems because there is zero security. I think we can do a bit better.
If it becomes a requirement, then there are other areas we should be looking into.
Definitely; although this is feature might not be a bad place to start. For others, we should probably discuss them in other issues.
It is as real as they want... as they can re-generate their key once in a while. In this sense, it is equivalent to making serviceId required.
I think there may be a disconnect between what we have in mind because having API id-secret style authen/autho is totally different from simply making serviceId required. A rough idea that I had in mind (could always just use OAuth1/2):
Client(name: String, credentials: Seq[Credentials])
Credentials(id: String, secret: String)
HttpPartConfig(... authorisedClients: Seq[Client]...)
The general idea is that authentication is done when a request comes into Octoparts using id and shared secret (Credential
), so we end up with a Client
. Then for each PartRequest, we check if the Client is authorised to hit that endpoint using the authorisedClients
of the corresponding HttpPartConfig
.
I see, OP's original idea is to have the client send API key per part...
Thank you for your response.
Let backend services more closely track/control who calls their APIs.
Although we don't always need such a feature, we sometimes need to figure out clients especially for sensitive APIs. Furthermore, this feature may improve not only security but troubleshooting on production environment.
If we could do the following things on admin UI, that will be great.
If we could set multiple targets (parts or services) flexibly, that'll be better. Creating new model such as AuthoriazationRule
which can hold partIds or serviceIds? Just an idea.
I'd like to contribute this feature when I have time.
To summarize this discussion :
Thanks. In our use cases, this feature looks like a YAGNI thing right now. Realistically, we already have lots of Octoparts aggregation API calls without API keys. Just to distinguish Octoparts clients, sending their own cilent identifiers (hostname, env/config variable) as a request header (e.g. X-Octoparts-Cient-Id) will be useful enough. If such a feature is already demanded, I will work on this.
Suggested by @seratch
Let backend services more closely track/control who calls their APIs.
The idea: