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

Authentication on workspace agent #5434

Closed
skabashnyuk opened this issue Jun 22, 2017 · 4 comments
Closed

Authentication on workspace agent #5434

skabashnyuk opened this issue Jun 22, 2017 · 4 comments
Assignees
Labels
kind/planning A checklist of issues for planning a particular sprint. kind/task Internal things, technical debt, and to-do tasks to be performed. status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it.

Comments

@skabashnyuk
Copy link
Contributor

The main difference between wsmaster and wsagent authentification is that wsagent is a completely untrusted environment. We can't store any system-wide secrets here. We have such options.

  • Reuse machine token authentication from Codenvy
  • Dynamically register new OpenId clients for each workspace and grant access to only for a particular set of users who have permissions to use it.
@skabashnyuk skabashnyuk added kind/planning A checklist of issues for planning a particular sprint. kind/task Internal things, technical debt, and to-do tasks to be performed. status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. labels Jun 22, 2017
@mshaposhnik mshaposhnik self-assigned this Jul 17, 2017
@mshaposhnik
Copy link
Contributor

mshaposhnik commented Jul 17, 2017

So we investigated a few ways to make agent authentication; Still not have strong opinion which one is better to choose.

  1. Pure Keycloak auth with shared token between master and agents - simplest way, easiest to implement, but not secure enought - it's easy to retrieve token on another's WS and do bad things on master with it.

  2. Use machine authentication from Codenvy on agents - so agents are totally uncoupled from Keycloak auth, use their own tokens to access master and agent API. This way has a higher complexity to implement, need to manage at least two (or more) tokens for each user on master, and choose them depending on where the request goes, probably even use two different request factories. This way also depends on permissions, so they are must be adapted in some form from Codenvy also.

  3. Pure Keycloak auth with separate Keykloak token for master and agent. This is the way which RH guys seems to be tried on theis side, AFAIK without success yet. We haven't tried it for this moment of time. It has also some complexity (i.e. obtaining the token duing agent startup to be able to make requests to me master during that, using different public and private realms e.t.c) but looks pretty logical for me personally.

@garagatyi
Copy link

I think in #3 it should be a token for the whole workspace, not just 1 agent. WDYT?

@mshaposhnik
Copy link
Contributor

More about 2 - it is possible situation, when requests came from agent to the master having machine token only, and not possible to do any keycloak actions like roles validating e.t.c. Also it is requires huge overhead transforming KC tokens into machine tokens on requests to agents, skipping machine tokens in filter, etc

@mshaposhnik
Copy link
Contributor

Done using machine auth;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/planning A checklist of issues for planning a particular sprint. kind/task Internal things, technical debt, and to-do tasks to be performed. status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it.
Projects
None yet
Development

No branches or pull requests

3 participants