Migration with Keycloak

[jvillafanez]

There are several problems to tackle at the moment:

• Setup issues:
  • The OC10's openidconnect app doesn't seems to work without HTTPS (PKCE issue even after removing the cookie setting as documented).
  • SSL certificate check can't be disabled for the openidconnect app. I had to touch the code to disable the check (not sure if it's worthy to allow this from the configuration because admins should use valid certificates anyway)
• Migration issues:
  • Users to be migrated MUST have logged in at least once in BOTH systems. This will cause problems.
    • The user must have logged in OC10 to it's known to the migration tool.
    • If the user hasn't logged in oCIS, the migration tool won't find the user when it needs to assign roles, transfer files, etc.
  • The migration tool uses the OC10 username to find users in oCIS. If OC10's Keycloak isn't properly configured the migration tool won't find the users in oCIS, which will cause problems.
    • I think the default configuration for the openidconnect will use the email as OC10 username. This conflicts with the default Keycloak setup we have for oCIS.
    • For these cases, we could setup the OC10 username of each user either manually or via script. However, we don't have an easy way to do it at the moment, and we'll need some time to implement a proper solution.
    • Since we should consider the OC10's Keycloak client as base, the oCIS' one might need to be compatible with the OC10 one. This means that, if OC10 is using the email as username, the oCIS client will need to also use the email as username.

[DeepDiver1975]

🤖 Automated issue triage by Claude Code review agent.

Triage: analysis-only — this reads as an internal investigation/task tracking several distinct blockers for oc10 → oCIS migration when Keycloak is the IdP, rather than a single located defect with one obvious fix. Summarizing so the work items are explicit:

Setup blockers (OC10 side, openidconnect app)

• OIDC reportedly doesn't work without HTTPS (PKCE issue persisting even after the documented cookie tweak).
• The TLS/SSL verification for the openidconnect app can't be disabled via config — required a code change. As noted, admins should use valid certs, so a config toggle here is debatable and is itself a product decision rather than a clear bug.

Migration blockers (identity mapping)

• Precondition: a user must have logged in to both systems before migration — into OC10 so the migration tool knows them, and into oCIS so the tool can resolve them for role/file assignment. This is a usability/sequencing constraint worth documenting prominently.
• Core mapping issue: the migration tool resolves oCIS users by the OC10 username. If the OC10 Keycloak client maps the username to email (the likely default) while the oCIS Keycloak client uses a different username claim, the tool can't find the users.
  • The practical fix direction stated here — make the oCIS Keycloak client's username claim consistent with the OC10 client (e.g. both use email) — is sound, but it's a configuration/alignment recommendation, not a code defect in the tool.
  • The missing piece is tooling to set/override each user's OC10 username in bulk (manual or scripted), which is genuinely new work.

So this issue mixes (a) documentation needs (login-to-both precondition; Keycloak client claim alignment), (b) a product decision (whether to expose a TLS-verify-disable config for the OC10 OIDC app), and (c) a feature gap (bulk OC10-username mapping tooling). None is a single isolated bug, so no fix is being auto-proposed.

Recommendation: split the feature gap (bulk username mapping) into its own tracked item, document the login-to-both and Keycloak-claim-alignment requirements, and decide separately on the TLS-verify config option. Happy to help once any one of these is scoped to a concrete change.