Qualche giorno fa sono andato a trovare un mio grande amico, che mi ha accolto indossando la maglietta in figura.
Ho subito capito che aveva indossatto la maglietta in mio onore, poichè la scritta era celebrativa per la serie che stavo scrivendo, e di cui questo post fa parte.
Evidentemente l'occhiata cui faceva riferimento era alle configurazioni introdotte sui servizi Azure Mobile, e di cui ho parlato nei post precedenti.
Il mio amico dapprima ha negato la connessione tra la mia serie e la sua maglietta, ma poi, dopo alcune mie insistenze, ha confermato le mie supposizioni.
Non ho capito molto il referimento al ginecologo, ma lo stesso amico mi ha assicurato che mi avrebbe spiegato nei prossimi giorni.
Per questo motivo ho pensato di mettere la foto che ritrae la sua bellissima T-Shirt: ho anche deciso di parlarne qui per sfatare il falso mito che chi si occupa di informatica non capisce mai le battute o le frasi spiritose !
Non la si fa a Giampaolo TUCCI !
Premesso questo fatto buttiamoci nella parte finale dell'autenticazione server-flow.
Quando ho esposto la configurazione all'interno del portale Azure per l'autenticazione in analisi avevo detto che avrei discusso del campo Allowed External Redirect URLs.
L'autenticazione server-flow con l'utilizzo dell'SDK Azure Mobile Client richiede che si definisca un nuovo URL Schema nonchè un host per la nostra app. L'URL Schema sono quei caratteri prima dell'indirizzo in un URL.
<URL Schema>://<Host>
L'utilizzo è quello di permettere il redirect dei servzi Azure al device (step 4 autenticazione server-flow - vedi post precedenti).
Entrambi i valori possono essere associati a stringhe arbitrarie, l'importante è che si seguano scrupolosamente i seguenti punti.
- Siano univoche all'interno della nostra app
- L'URL completo sia dichiarato nel portale Azure in Authentication / Authorization voce Allowed External Redirect URLs
- La app abbia specificato i valori prescelti all'interno del file AndroidManifest.xml
Direi che ora occorre presentare quelli che ritengo alcuni elementi critici circa questa modalità di autenticazione.
- Per il processo di autenticazione si usa una WebView (nelle versioni più recenti Custom Chrome Tab), che quindi può offrire una scarsa "esperienza di utilizzo": un utente obbligato a inserire una userid e password in un browser dopo aver lanciato una app per inserire i posti migliori dove si mangia la vera focaccia genovese (Vi ricordate ? Lo scopo della nostra app...) potrebbe giudicare negativamente il nostro software
- L’autenticazione server-flow nell’SDK Azure è stato recentemente profondamente modificato per soddisfare nuovi requisiti di sicurezza: potrebbe succedere la stessa cosa nel futuro per analoghe esigenze.
- Difficoltà nel gestire il logout: possono rimanere nel browser del dispositivo cookie o password memorizzate che forzano l’autenticazione anche se si è eseguito esplicitamente il logout
- Se nel nostro dispositivo abbiamo per esempio già la app dell’IdP non è possibile riutilizzare l’accesso già ottenuto per questa. Cioè se percaso nel nostro cellulare è già presente la app di Facebook, per il quale si è già eseguioto l'accesso, al lancio della nostra app si dovrà nuovamente inserire userid e password.
Per inciso: io NON ritengo personalmente i downside esposti sopra dei "gran problemi", però, insomma, qualcuno potrebbe pensarla diversamente. Inoltre in molte documentazioni M$ sull'argomento si presenta la cosa con questi toni, e quindi...... io mi adeguo ..... anche se non ne sono convinto......
Comunque quello che mi sento di dire che se non vi agita presentare un software che lancia una pagina browser per autenticare l'accesso, allora l'autenticazione server-flow fa perfettamente al caso Vostro.
Se siete rognosi e volete una "esperienza di utilizzo più omogenea" (?!) allora è necessarrio introdurre l'autenticazione client-flow.
Linkografia