Blank UI after successful SAML2 SSO login for non-root-admin users (`primate__MS_ID` stored as `"undefined"`)

Aperta
#14,455 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, javascript

Direzione di ricerca

Start in ui/src/permission.js at the SAML branch that commits the managementserverid cookie, then read SET_MS_ID in ui/src/store/modules/user.js and compare with the native login guard in user.js. Reproduce with a non-root SAML login and inspect primate__MS_ID and the GetInfo error. Done means the UI loads without persisting an undefined ID, while root-admin and native login behavior remains intact.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
problem
COMPONENT NAME

UI, SAML2 plugin

CLOUDSTACK VERSION

4.22.1.1 (the code paths below are verified in tag 4.22.1.1)

CONFIGURATION
  • KVM, Advanced zone
  • SAML2 plugin enabled, IdP: Keycloak (SP-initiated, HTTP-POST binding)
  • User authorized for SAML SSO via authorizeSamlSso; role type DomainAdmin (same username present in two domains)
SUMMARY

After a successful SAML2 SSO login, the UI never finishes loading (blank page or endless spinner) for any user who is not a Root Admin. Native login for the same user works. All APIs called with the SAML session return HTTP 200 (listCapabilities, listApis, listUsers, listZones, listAndSwitchSamlAccount), so the server-side session is valid. The failure is entirely in the UI.

versions
CLOUDSTACK VERSION

4.22.1.1 (the code paths below are verified in tag 4.22.1.1)ons of ACS, hypervisors, storage, network etc..

The steps to reproduce the bug
STEPS TO REPRODUCE
  1. Enable SAML2 (saml2.enabled=true) and configure an IdP.
  2. Authorize a Domain Admin or User for SAML SSO.
  3. Log in through the IdP.
  4. After the redirect back to /client, the UI stays blank.
EXPECTED RESULTS

The UI loads the dashboard.

ACTUAL RESULTS

Browser console:

SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
    get            webStorage.js:20
    GetInfo        user.js:319
    ...            permission.js:104
Uncaught (in promise) TypeError: can't convert undefined to object
    GenerateRoutes permission.js:74

localStorage.getItem('primate__MS_ID') returns the literal string "undefined", and no managementserverid cookie is set after samlSso.

What to do about it?
ROOT CAUSE
  1. Server: ApiServer.loginUser() only puts managementserverid into the session for root admins:
    if (accountMgr.isRootAdmin(userAcct.getAccountId())) {
        ... session.setAttribute(ApiConstants.MANAGEMENT_SERVER_ID, msHost.getUuid());
    }
    
    For any other user, SAMLUtils.addBaseCookies() therefore sets no managementserverid cookie. That part is correct and intended.
  2. UI, SAML branch (ui/src/permission.js): the UI commits the cookie value without checking it:
    store.commit('SET_MS_ID', Cookies.get('managementserverid'))   // undefined for non-root users
    
    The native login path in user.js does guard against this (if (result && result.managementserverid)).
  3. UI store (SET_MS_ID in ui/src/store/modules/user.js) persists the value as is: $localStorage.set(MS_ID, undefined). This leaves primate__MS_ID = "undefined" in localStorage.
  4. On the next GetInfo, $localStorage.get(MS_ID, false) calls JSON.parse("undefined"), which throws. GetInfo rejects, GenerateRoutes receives undefined, and no routes are generated. The UI stays blank.

Clearing localStorage does not help, because the permission.js SAML branch writes the bad value again on every page load.

WORKAROUND

Once the page is blank, run this in the browser console (any non-empty value works, because only root admins use msId):

document.cookie = 'managementserverid=<ms-uuid>; path=/client';
localStorage.setItem('primate__MS_ID', JSON.stringify({ value: '<ms-uuid>', expire: null }));
location.reload();
PROPOSED FIX

A patch is attached (saml-msid-fix.patch):

  1. ui/src/permission.js: commit the management server ID only when the cookie exists. Also check path: '/client', consistent with the other SAML cookies.
    const msId = Cookies.get('managementserverid') || Cookies.get('managementserverid', { path: '/client' })
    if (msId) {
      store.commit('SET_MS_ID', msId)
    }
    
  2. ui/src/store/modules/user.js: make SET_MS_ID safe so it never persists undefined, which also protects any other caller:
    SET_MS_ID: (state, msId) => {
      state.msId = msId || ''
      if (msId) {
        vueProps.$localStorage.set(MS_ID, msId)
      } else {
        vueProps.$localStorage.remove(MS_ID)
      }
    },
    
  3. SAMLUtils.addBaseCookies() (consistency): create the managementserverid cookie with the same domain and path as the other SAML cookies (newCookie(domain, path, ...) instead of new Cookie(...)). Then root admins get the cookie on the redirect target path even when saml2.redirect.url has a different path from the ACS endpoint.

Fixes 1 and 2 on their own resolve the bug. Fix 3 is a hardening change.

TESTING
  • SAML login as Root Admin: managementserverid cookie set, primate__MS_ID holds the UUID, shutdown and maintenance banner checks work.
  • SAML login as Domain Admin or User: no cookie, no primate__MS_ID entry, UI loads.
  • Native login and logout: unchanged (logout calls SET_MS_ID(''), which now removes the key).
  • Users whose browser already holds a stale primate__MS_ID = "undefined": optionally make GetInfo tolerate unparsable values. With fix 2 in place, the next SAML login removes the key, but GetInfo runs before that, so a one-off cleanup in permission.js, or a try/catch around the storage get, would make the upgrade path seamless.
Lingua principale
Java
Stelle
3.1k
Fork
1.4k
Merge medio
7g 16h
PR unite (30g)
15

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/cloudstack

Tutte le issue di apache/cloudstack

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.