[full-ci] set demo users to default off

[micbar]

Description

Disable the creation of the demo users by default

Tasks

• Default value should be false
• adjust CI
• adjust Demo Deployments
• adjust DevDocs

Related Issue

• Fixes Disable the creation of the demo users by default #3181

Motivation and Context

• Strengthen the security

How Has This Been Tested?

• CI
• Manually

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change, it changes the default behavior
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[ownclouders]

💥 Acceptance test localApiTests-apiArchiver-ocis failed. Further test are cancelled...

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[mmattel]

This is confusing and needs clearance before merging:

• An env is presen ACCOUNTS_DEMO_USERS_AND_GROUPS but it states in the remark its immediate depreciation when switching to something different internally?
• In parallel a second env is present IDM_CREATE_DEMO_USERS - reason, use?
• Then we have a third env named DEMO_USERS...
• When you have decided to have the demo users created, what is the process to disable them?
  Is it just to not use the env? or do you need additional steps? Asking because there is a difference in the term creation (persistance, needs deletion in case) and use (enable/disable).
• To create an ordinary admin, you have to create the demo users, create the new admin account and then delete/disable the demo users again? (+ can you do this on the command line or is web necessary?)

@EParzefall fyi

[micbar]

This is confusing and needs clearance before merging:

• An env is presen ACCOUNTS_DEMO_USERS_AND_GROUPS but it states in the remark its immediate depreciation when switching to something different internally?

We are in a two-step transition. The accounts service will be deleted in the next 2 weeks, but before we need this move

• In parallel a second env is present IDM_CREATE_DEMO_USERS - reason, use?

That will be the value after we remove the accounts service

• Then we have a third env named DEMO_USERS...

This is not in the code, it is just in the demo deployments, another abstraction layer like INSECURE

• When you have decided to have the demo users created, what is the process to disable them?

Remove them manually

Is it just to not use the env? or do you need additional steps? Asking because there is a difference in the term creation (persistance, needs deletion in case) and use (enable/disable).

creation, it means the accounts are persisted

• To create an ordinary admin, you have to create the demo users, create the new admin account and then delete/disable the demo users again? (+ can you do this on the command line or is web necessary?)

Like stated in the docs, we always create the admin and the idp user (internal). Changing their credentials is currently only possible via the CLI. In the future, after the switch to IDM, the initial passwords can be set by a config variable.

@EParzefall fyi

@mmattel @EParzefall I admit, the whole ocis config is still very confusing. It will change another time before beta.

We need to merge this change here to make it more secure.

The switch to LibreIDM will happen in the next sprint. And it will create a bunch of new documentation and config options.
#3259

[micbar]

@mmattel @EParzefall I am not sure if the whole demo users topic should be in the admin docs. For the admins, it is important that they know how to deploy a secure ocis in production. BTW this is the reason why we change the default behavior. You only get the demo users when you explicitly want them. This prevents insecure oCIS instances out there where demo users are present and the admin is not aware of them.

[mmattel]

The documentation of the demo users is definitely necessary for the admin docs, means creation, removal, warning ect. This has to be in because one will find the env and gives it a try. As it is in the docs, he then knows the impact and how to remove properly.

I will use the new env and not the old one as you said it will get removed soon. Not worth doing double work - but I will hook myself into the referenced issue to get notified when it is merged.

[mmattel]

Like stated in the docs, we always create the admin and the idp user (internal)

Q: as far I have understood and read in dev.docs, the "admin" user created is part of the demo users. I understand the IDP user which is not part of the demo users but where is that written. Did I missed something?

If I got it right, to create a new admin user, you use ocis accounts create and grant rights -or?

[micbar]

@mmattel Please let us not bother with the old accounts CLI.

We merge this and use this the next 2 weeks. Then switch to LibreIDM

[mmattel]

I do not know what is old and what is new and what the differences and impacts are...

[micbar]

everything with the noun accounts is going to removed from oCIS.

We never wanted to do user management in ocis. Creating the accounts service was a mistake in the past.

In the future we will only rely on an external Identity Management.

For the out of the box use case, like "Download and start" we will ship a replacable Identity Management System called LibreIDM which is part of the owncloud & Kopano collaboration.

So what does that mean for you and the docs:

IMO the admin docs should focus on how to connect an external IDP.

We do not know yet, how much the LibreIDM scales. We suppose it will only be supported for very small use cases.

So the mesage would be:

1. LibreIDM for testing"or small deployments. Remember, oCIS should run on a raspberry PI
2. Real LDAP (like openLDAP or microsoft AD) server and IDP (like keycloak, ping, azure) if you are serious about your ocis instance.

This PR is mainly about changing the CI and the Demo Deployments. It should be merged ASAP.

[micbar]

everything with the noun accounts is going to removed from oCIS.

We never wanted to do user management in ocis. Creating the accounts service was a mistake in the past.

In the future we will only rely on an external Identity Management.

For the out of the box use case, like "Download and start" we will ship a replacable Identity Management System called LibreIDM which is part of the owncloud & Kopano collaboration.

So what does that mean for you and the docs:

IMO the admin docs should focus on how to connect an external IDP.

We do not know yet, how much the LibreIDM scales. We suppose it will only be supported for very small use cases.

So the mesage would be:

1. LibreIDM for testing or small deployments. Remember, oCIS should run on a raspberry PI
2. Real LDAP (like openLDAP or microsoft AD) server and IDP (like keycloak, ping, azure) if you are serious about your ocis instance.

This PR is mainly about changing the CI and the Demo Deployments. It should be merged ASAP.