Skip to content
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

@coderanger
Copy link
Contributor

@coderanger coderanger commented Nov 8, 2014

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

Hot off the presses, have at it!

@jtimberman
Copy link
Contributor

@jtimberman jtimberman commented Nov 9, 2014

I think this is relevant perhaps to oc-id?

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

Loading

@coderanger
Copy link
Contributor Author

@coderanger 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.

Loading

@coderanger
Copy link
Contributor Author

@coderanger 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.

Loading

@jamesc
Copy link

@jamesc 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.

Loading

@coderanger
Copy link
Contributor Author

@coderanger 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.

Loading

@danielsdeleo
Copy link
Contributor

@danielsdeleo 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.

Loading

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`.
Copy link

@seth seth Nov 9, 2014

Choose a reason for hiding this comment

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

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

Loading

Copy link

@seth seth Nov 9, 2014

Choose a reason for hiding this comment

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

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?

Loading

Copy link
Contributor Author

@coderanger coderanger Nov 10, 2014

Choose a reason for hiding this comment

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

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.

Loading

@thommay
Copy link
Collaborator

@thommay thommay commented Feb 19, 2015

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

Loading

@adamhjk
Copy link
Contributor

@adamhjk adamhjk commented Feb 19, 2015

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

Loading

@jonlives jonlives merged commit 93e185b into chef-boneyard:master Feb 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
9 participants