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

IDP should autogenerate certificate and secret #3909

Closed
wkloucek opened this issue Jun 2, 2022 · 3 comments · Fixed by #4022
Closed

IDP should autogenerate certificate and secret #3909

wkloucek opened this issue Jun 2, 2022 · 3 comments · Fixed by #4022
Assignees
Labels
Category:Enhancement Add new functionality Priority:p2-high Escalation, on top of current planning, release blocker Topic:good-first-issue

Comments

@wkloucek
Copy link
Contributor

wkloucek commented Jun 2, 2022

Is your feature request related to a problem? Please describe.

The IDP autogenerates a certificate and secret inmemory to sign sessions. This means a restart yields a new certificate and secret and therefore invalidates all sessions.

Describe the solution you'd like

The IDP should autogenerate and persist the certificate and secret on disk by default.

Describe alternatives you've considered

You can generate a certificate and a secret manually, so that your sessions survive a restart:

openssl rand -out /etc/ocis/idp-encryption.key 32
openssl genpkey -algorithm RSA -out /etc/ocis/idp-private-key.pem -pkeyopt rsa_keygen_bits:4096

Then you need to configure the IDP to use them:

IDP_SIGNING_PRIVATE_KEY_FILES=/etc/ocis/idp-private-key.pem
IDP_ENCRYPTION_SECRET_FILE=/etc/ocis/idp-encryption.key

Additional context

Having the certificate on disk can also prevent a split-brain situation, if you deploy oCIS on two servers. If they share the same data volume (eg. NFS share), they just use the same certificate and secret. If the have it in memory they create sessions only valid for themselves, which is fatal in round robin load balanced situations.

@micbar micbar added the Priority:p2-high Escalation, on top of current planning, release blocker label Jun 2, 2022
@C0rby
Copy link
Contributor

C0rby commented Jun 22, 2022

Having the certificate on disk can also prevent a split-brain situation

But auto generating the certificate could also lead to a split-brain situation when we deploy multiple idp services.
Or should these setups not generate their own certificates.

@wkloucek
Copy link
Contributor Author

wkloucek commented Jun 22, 2022

Having the certificate on disk can also prevent a split-brain situation

But auto generating the certificate could also lead to a split-brain situation when we deploy multiple idp services. Or should these setups not generate their own certificates.

If we only generate once and have shared storage (we need that also for the autogenerated ldap ca for the idm and all ldap-consuming services), then we should be fine.

Preferably, distributed systems will not rely on the auto generation. Eg. our oCIS Helm chart will provide external certificates.

@C0rby
Copy link
Contributor

C0rby commented Jun 23, 2022

That's true. Ok, let me try to implement something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category:Enhancement Add new functionality Priority:p2-high Escalation, on top of current planning, release blocker Topic:good-first-issue
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants