Chi può installare le app del Marketplace
La domanda «i miei utenti possono installarsi le app di terze parti?» ha una risposta sola, e vive in Apps > Google Workspace Marketplace > Settings, nell’impostazione Manage access to apps. Le tre scelte sono nette: consentire l’installazione di qualunque app, consentire solo le app in allowlist, oppure non consentire alcuna installazione. Solo la scelta intermedia rende l’allowlist significativa: con la prima l’elenco delle app approvate non produce alcun effetto, con la terza nessuno installa nulla e l’unica strada resta l’installazione decisa dall’amministratore.
L’allowlist si costruisce in Apps > Google Workspace Marketplace apps > Apps list, con il pulsante Allowlist app: si cerca l’app, la si consente e si sceglie il perimetro, l’intera organizzazione oppure unità organizzative e gruppi specifici. Attenzione al comportamento implicito: quando consenti un’app solo ad alcune unità organizzative, per tutte le altre risulta automaticamente esclusa, senza bisogno di un blocco esplicito. E ricorda l’effetto della rimozione, che è la trappola classica di questo obiettivo: togliere un’app dall’allowlist toglie l’accesso agli utenti anche a chi l’aveva già installata.
Distribuire un’app non è la stessa cosa che permetterla
Consentire e distribuire sono due gesti diversi. Con l’allowlist decide l’utente se installare o no; con l’installazione a livello di dominio è l’amministratore a installare l’app per un’unità organizzativa o per tutti, e l’app compare senza che il singolo debba muovere un dito. La prima via è adatta agli strumenti opzionali, la seconda al componente aggiuntivo che tutto il reparto deve avere il primo giorno.
Sul versante Android il ragionamento è identico, ma cambiano il negozio e il prerequisito: la distribuzione di app agli smartphone gestiti passa dalla gestione delle app dei dispositivi mobili, disponibile soltanto con advanced mobile management. Con la basic mobile management puoi proteggere l’account sul telefono, non decidere che cosa vi è installato. È il criterio che distingue un requisito del tipo «vogliamo un catalogo aziendale di app sui telefoni» da uno che la gestione di base riesce ancora a soddisfare.
SSO verso le app di terze parti, con Google come IdP
Molte app SaaS accettano Google come identity provider SAML, e la configurazione parte da Apps > Web and mobile apps > Add app > Add custom SAML app. Google ti mostra la sua metà dello scambio nella pagina Google Identity Provider details: SSO URL, Entity ID e certificato, scaricabili anche come file IDP metadata da caricare nel pannello del fornitore. Tu restituisci la metà opposta, quella del service provider: ACS URL, che riceve la risposta SAML e deve iniziare con https, Entity ID dell’app, Start URL opzionale per il parametro RelayState e, se il fornitore lo richiede, l’opzione Signed response.
Restano due passaggi che spiegano la maggior parte dei ticket di accesso negato. Il primo è il Name ID, che per impostazione predefinita è l’indirizzo email principale dell’utente: se l’app riconosce le persone da un altro identificativo, il valore va cambiato qui. Il secondo è la mappatura degli attributi, dove porti nella risposta SAML i campi della directory che l’app si aspetta, inclusa l’appartenenza ai gruppi. Alla fine l’app va accesa in User access per le unità organizzative o gli access group giusti, altrimenti l’autenticazione fallisce anche con una configurazione perfetta. Il pulsante Test SAML login verifica il flusso IdP-initiated; per quello SP-initiated si parte dall’URL dell’app e si controlla di essere rimandati alla schermata di accesso Google.
Servizi Google aggiuntivi e app connesse da revocare
Oltre ai servizi core, il tenant espone gli Additional Google services: YouTube, AdSense, Blogger e simili, gestiti in Apps > Additional Google services. Ognuno si accende o si spegne per unità organizzativa, e con gli access group puoi darne accesso a un insieme di persone che non coincide con l’albero organizzativo, per esempio solo al team marketing. Verifica anche il comportamento per i servizi introdotti in futuro, governato dall’impostazione che li attiva o disattiva automaticamente, e metti in conto fino a 24 ore di propagazione prima di dichiarare fallito un cambiamento.
La chiusura del cerchio è la revoca. In Security > Access and data control > API controls trovi Manage Third-Party App Access con le app già autorizzate, divise fra Configured apps e Accessed apps: selezionandone una puoi portarla a Trusted, Limited o Blocked, e i token vengono revocati entro 48 ore. Nella stessa pagina decidi che cosa accade alle app non ancora configurate, dal blocco totale al permesso per le sole app che chiedono i dati di accesso Google, e rivedi in Apps pending review le richieste inviate dagli utenti, ordinate per numero di richiedenti. Per il singolo utente, infine, le autorizzazioni si tolgono dalla sua scheda in Directory > Users, nella sezione delle applicazioni connesse: è il gesto giusto quando il problema è una persona, non un’app.