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

[Feature request] Import clients on startup #140

Closed
janekolszak opened this issue Jul 13, 2016 · 13 comments
Closed

[Feature request] Import clients on startup #140

janekolszak opened this issue Jul 13, 2016 · 13 comments
Assignees
Labels
feat New feature or request.
Milestone

Comments

@janekolszak
Copy link

Can we have an option to import clients when hydra's starting? Something like:

hydra host --import clients.json

and clients.json:

[
{ client_1},
{ client_2}
]

There's hydra clients import client.json, but it needs client's credentials and I don't want to paste this every time from command line.

Use case:

  • On hydra's startup I need to add couple of predefined clients for IDPs and have hydra add them to the database.
  • On next startup hydra should ensure that all clients from the list are present, possibly update the configuration.
@aeneasr
Copy link
Member

aeneasr commented Jul 13, 2016

what rights should the imported clients have?

@aeneasr aeneasr added the feat New feature or request. label Jul 13, 2016
@janekolszak
Copy link
Author

You mean scopes?

@aeneasr
Copy link
Member

aeneasr commented Jul 13, 2016

by default, clients aren't allowed to read/write json web keys, create new clients, ...

@janekolszak
Copy link
Author

Oh, I thought that's the "hydra" scope. Of course I need those rights to be added to the imported clients. Those are the clients for the IDP instances.

hydra host --idp idp_clients.json

and idp_clients.json:

[
{ client_1},
{ client_2}
]

Alll other clients that don't need admin rights will be created with hydra clients import.

@aeneasr
Copy link
Member

aeneasr commented Jul 13, 2016

we should figure out some better semantics - --idp doesn't really imply that it's an administrative account. i also don't really like the idea of the file being looked up on every host boot. wouldn't it be enough to specify the id and secret on first boot?

@aeneasr
Copy link
Member

aeneasr commented Jul 14, 2016

something like:

FORCE_CLIENT_CREDENTIALS=base64(foo:bar) hydra host

@janekolszak
Copy link
Author

If this client is only described by id/secret then a file is pointless and parameters will leak via /proc.

So maybe good old env variable checked when client is starting?

@aeneasr
Copy link
Member

aeneasr commented Jul 14, 2016

Ok just to check - so this would be fine for you?

FORCE_CLIENT_CREDENTIALS=base64(foo:bar) hydra host

@janekolszak
Copy link
Author

janekolszak commented Jul 14, 2016

  • What's the base64 function? You mean base64 of id:secret?
  • hydra host are the scopes?

@aeneasr
Copy link
Member

aeneasr commented Jul 14, 2016

What's the base64 function? You mean base64 of id:secret?

Yes, base64 of id:secret. Thought it might help with binary passwords.

hydra host are the scopes?

No, that's the hydra host command! In Unix you can set environment variables per process with KEY=VALUE <command>

@janekolszak
Copy link
Author

Oh yes, sorry. Looked like a peculiar env export :)
It's ok. I will define that in docker-compose file.

I don't think accepting binary passwords is worth the extra function invocation.
People will get confused (yet another step, just to pass the temporary, most probably developer credentials)

@janekolszak
Copy link
Author

And with base64() I won't be able to fit this into docker-compose file...

@aeneasr
Copy link
Member

aeneasr commented Jul 14, 2016

I don't think accepting binary passwords is worth the extra function invocation.
People will get confused (yet another step, just to pass the temporary, most probably developer credentials)

You're right - let's keep it simple :)

@aeneasr aeneasr self-assigned this Jul 24, 2016
@aeneasr aeneasr added this to the 0.2.0 milestone Jul 24, 2016
aeneasr pushed a commit that referenced this issue Jul 25, 2016
@aeneasr aeneasr closed this as completed Jul 25, 2016
aeneasr pushed a commit that referenced this issue Aug 9, 2016
* warden: rename `assertion` to `token` - closes #158
* config: do not log database credentials - closes #147
* oauth2: upgrade fosite - close #160
* config: do not store database config in hydra config - closes #164
* oauth2: id_token at_hash / c_hash is null - closes #129
* jwk: improve error message of wrong system secrect - closes #104
* readme: improve images, add benchmarks - closes #161
* cmd: improve connect dialogue - closes #170
* cmd: fix --dry option - closes #157
* firewall: document warden interface sdk
* readme: link openid connect and oauth2 introduction
* cmd: introduce FORCE_ROOT_CLIENT_CREDENTIALS env var - closes #140
* readme: document error redirect to identity provider - closes #96
* internal: fosite store must be consistent to avoid errors - closes #176
* client: add GetConcreteClient to http manager
* cmd: host process now logs basic information on all http requests - closes #178
* all: add memory profiling - closes #179
* warden: resolve nil pointer issue - closes #181
* cmd: clean up env to struct mapping, add more controls
* cmd: bcrypt cost should be configurable - closes #184
* cmd: token lifespans should be configurable - closes #183
* cmd: resolve issues with envirnoment config - closes #182
* cmd: implement tls termination capability - closes #177
* cmd: resolve issues with redirect logic and TLS
* oauth2: implement default oauth2 consent endpoint - closes #185
* warden - closes #188 
* oauth2: id token claims should be set by using id_token - closes #188
* oauth2: oauth2 implicit flow should allow custom protocols - closes #180
* oauth2: core scope should not be mandatory - closes #189
* warden: warden sdk should not make distinction between token and request - closes #190
* warden: rename authorized / allowed endpoints to something more meaningful - closes #162
* ci: improve travis config
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

No branches or pull requests

2 participants