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

Token authentication for Chef Server #65

Merged
merged 4 commits into from Feb 19, 2015

Conversation

Projects
None yet
9 participants
@coderanger
Copy link
Contributor

coderanger commented Nov 8, 2014

Ping @smith @seth @mmzyk @danielsdeleo @lamont-granquist.

Hot off the presses, have at it!

@jtimberman

This comment has been minimized.

Copy link
Member

jtimberman commented Nov 9, 2014

I think this is relevant perhaps to oc-id?

https://github.com/opscode/oc-id

@coderanger

This comment has been minimized.

Copy link
Contributor

coderanger commented Nov 9, 2014

@jtimberman Yes, it would allow clients of oc-id to talk directly to the Chef Server after completing the Oauth2 cycle.

@coderanger

This comment has been minimized.

Copy link
Contributor

coderanger commented Nov 9, 2014

I would also like to state for the record that while I'm writing this up, I think this would be beyond the scope of something I could write on my own.

@jamesc

This comment has been minimized.

Copy link
Member

jamesc commented Nov 9, 2014

@coderanger The current version of oc-id supports generating tokens from either username/password (chef-boneyard/oc-id#27) or from Chef signed headers (chef-boneyard/oc-id#25).

I have a full token based auth cycle working in Chef analytics (using OAuth tokens from oc-id directly from JS or knife talking to erlang backend services). We'll be shipping this soon and then working on moving the same code in Chef.

We currently don't do support any OAuth scopes and a piece of remaining work is to work out how Chef org and object permissions map into scopes.

@coderanger

This comment has been minimized.

Copy link
Contributor

coderanger commented Nov 9, 2014

@jamesc Sounds like you were already planning similar work to this proposal then :) Guess I saved you some time writing it up.

@danielsdeleo

This comment has been minimized.

Copy link
Member

danielsdeleo commented Nov 9, 2014

I'm a big 👍 on this feature in general. Given the sensitive nature of authN stuff, I'd like to delegate as much of our standard to an upstream standard as possible so that we can follow the standard by using 3rd party implementations, and we can react to any flaws in the standard itself by upgrading to a newer version. I have to say that I'm pretty ignorant about OAuth2 in general so I can't say if the way this RFC is written meets my request or not.

This new token is associated with the client or user that issued the request to
create it.

Tokens must be 16 characters from the set `abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789`.

This comment has been minimized.

@seth

seth Nov 9, 2014

Member

Would it make sense to allow /, +, and = so that a base64 value can be used as a token?

This comment has been minimized.

@seth

seth Nov 9, 2014

Member

Is the 16 character specification something to fit an existing standard? A minimum to achieve security based on randomly generated tokens or of some other significance?

This comment has been minimized.

@coderanger

coderanger Nov 10, 2014

Contributor

I left them out because its a random string anyway so "base62" doesn't really hurt anything, and alphanumeric is less likely to conflict with anything while being a subset of the base64 charset. There is no standard for bearer tokens that I'm aware of, so I just picked something for the sake of being specific.

```
HTTP/1.1 200 OK
{"token": "<token>", "created_at": "1970-01-01T00:00:00Z"}

This comment has been minimized.

@seth

seth Nov 9, 2014

Member

What's the purpose of the created_at timestamp? Would it be worth removing this from the response for a first version?

This comment has been minimized.

@coderanger

coderanger Nov 10, 2014

Contributor

Backdoor feature request because I want this on all Chef data so why not get this one right from the start :) Usually creation just echos back the encoded object, which would include the timestamp just like GET.


### Generating a token

A new token can generated using the token API:

This comment has been minimized.

@seth

seth Nov 9, 2014

Member

Does creating a token require an already valid token or otherwise authenticated request? I was expecting only to exchange username and password for a valid token.

This comment has been minimized.

@coderanger

coderanger Nov 10, 2014

Contributor

The POST /tokens API uses normal Chef auth (so either key sig or an existing token), there is an example below of extending the /authenticate_user API to also create a token if requested. This one would mostly be used for things like delegating access from a knife plugin.

#### List

```
GET /tokens HTTP/1.1

This comment has been minimized.

@seth

seth Nov 9, 2014

Member

I'd be inclined to omit this endpoint. How would it be used?

This comment has been minimized.

@coderanger

coderanger Nov 10, 2014

Contributor

Web UI allowing people to delete existing tokens.

Host: chef.example.com
X-Ops-...: ...
{"expires": "1970-01-01T00:00:00Z"}

This comment has been minimized.

@seth

seth Nov 9, 2014

Member

Would the server also get to apply policy about token expiration? I can see wanting to implement a server-based policy that would disallow tokens living beyond some pre-set TTL. But I can also see the benefit of giving users the ability to create short-lived or long-lived tokens depending on their intended use.

This comment has been minimized.

@coderanger

coderanger Nov 10, 2014

Contributor

I don't see much value in a global max/min given the use cases are generally going to be tool-driven anyway (eg. knife token create).


Tokens must be 16 characters from the set `abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789`.

A new token can also be generated for a user from their username and password.

This comment has been minimized.

@randomcamel

randomcamel Nov 20, 2014

Isn't this contrary to good security practice?

This comment has been minimized.

@coderanger

coderanger Nov 20, 2014

Contributor

Not in a microservice-y world, this would be substantially more secure than the current setup.

This comment has been minimized.

@randomcamel

randomcamel Nov 20, 2014

Why do that instead of randomly generating the token?

This comment has been minimized.

@coderanger

coderanger Nov 20, 2014

Contributor

Not sure what you mean, tokens are randomly generated. This section describes an addition to the existing /authenticate_user API to also request a token be created when verifying username and password.

This comment has been minimized.

@randomcamel

randomcamel Nov 20, 2014

Ah. In that case, the wording "generated...from their username and password" should be cleared up.

@thommay

This comment has been minimized.

Copy link
Collaborator

thommay commented Feb 19, 2015

I am 👍 in principle whilst having no opinion on the technical details of the RFC

@adamhjk

This comment has been minimized.

Copy link
Contributor

adamhjk commented Feb 19, 2015

Lets 👍 this - we can revisit the details as we implement.

@jonlives jonlives merged commit 93e185b into chef:master Feb 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment