42 messaggi dal 10 giugno 2010
Buongiorno a tutti,

ho la necessità di sviluppare una serie di WebAPI per la scrittura / lettura dati da db.

L'iterazione dovrebbe avvenire dal web utilizzando mvc5 e knockout-js e da 3 app (windows phone, android, ipad).

Per poter accedere ai dati l'applicazione necessità di autenticazione da parte dei utenti.

Come posso sviluppare le web api in modo da rendere semplice la gestione dell'autenticazione? E' sufficiente utilizzare il modello presente in visual studio 2015 di applicazione web api?
Le web api verrebberò pubblicate nel cloud di Azure, eventualmente è possibile utilizzare già qualcosa integrato?

Grazie.
11.878 messaggi dal 09 febbraio 2002
Contributi
Ciao,
anziché scrivere una "normale" Web API e pubblicarla come App Web, potresti valutare un Azure Mobile Service. Puoi procurartelo dal nuovo portale di Azure (portal.azure.com) e poi cominciare a costruire un progetto da Visual Studio con il template chiamato "Servizio mobile di Azure" che trovi dentro "Cloud".

Un Mobile Service ti permette di creare rapidamente un backend per le tue app mobile. Qui trovi istruzioni per realizzare il client di ciascuna piattaforma.
https://azure.microsoft.com/it-it/documentation/services/mobile-services/

Puoi consumare il servizio anche da un'applicazione web, dato che esiste una libreria client per javascript.
https://msdn.microsoft.com/en-us/library/azure/jj554207.aspx

Inoltre guarda la sezione "Autenticare utenti" che trovi nella documentazione, che ti dà indicazioni su come sfruttare login provider esterni.
https://azure.microsoft.com/it-it/documentation/services/mobile-services/

Azure offre anche un altro servizio che ti potrebbe interessare e si chiama Mobile Apps. Valutalo, ma tieni presente che è ancora un servizio in preview e perciò non è ancora pronto per la produzione. Informazioni qui:
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-value-prop/

E questi sono i vantaggi rispetto ai Mobile Services.
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-value-prop-migration-from-mobile-services/

ciao,
Moreno
Modificato da BrightSoul il 01 dicembre 2015 15.05 -

Enjoy learning and just keep making
42 messaggi dal 10 giugno 2010
Ciao Moreno,

grazie per la risposta, come al solito molto precisa.

Se volessi però provare a fare l'autenticazione tramite web api tradizionali da app cosa potrei utilizzare?

Ho trovato in rete del materiale relativamente all'autenticazione tramite token, ma non so se è la strada corretta.

grazie mille.
11.878 messaggi dal 09 febbraio 2002
Contributi
Ciao,
tutto dipende da come vuoi far autenticare i tuoi utenti.
  • Devono poter usare il loro account social (Facebook, Google, Microsoft, ecc..) per accedere?
  • Si tratta di utenti che hanno già un proprio account in Azure Active Directory?
  • Gli utenti devono poter accedere all'app solo dopo essersi registrati da una pagina apposita?
  • Non è previsto alcun riconoscimento dell'utente, ma solo una protezione della Web API che consente solo alla app di fruirne?


ciao,
Moreno

Enjoy learning and just keep making
42 messaggi dal 10 giugno 2010
Ciao

in pratica ho la necessità di far registrare gli utenti e farli autenticare.

Gli utenti dovranno registrarti da una pagina, meglio dall'app (ios, android o windows phone). Pensavo di usare framework tipo ionic.

Le risorse a cui l'utente dovrà accedere saranno quelle autenticate.

In pratica dalla app gli utenti dovranno autenticarsi e accedere ad una loro area riservata.

Grazie mile
11.878 messaggi dal 09 febbraio 2002
Contributi
Ciao,
ok, ci sono vari approcci che puoi usare. Alcuni più semplici, altri più sicuri che ti mettono relativamente al riparo da attacchi di tipo replay. Vediamone qualcuno tra i più comuni, poi scegli quello che pensi faccia al caso tuo.
  • Basic authentication. L'utente inserisce le sue credeziali nel modulo di login e, da quel momento in poi, ogni volta che l'app invia una richiesta al server, includerà il suo username e password tra le intestazioni, in chiaro. Questo approccio è sicuro se le comunicazioni avvengono su HTTPS, ovvero devi installare un certificato SSL nel server. Può essere soggetto ad attachi di tipo replay.
  • Token. Simile al precedente ma, anziché inviare sempre username e password ad ogni richiesta, invia un token che ha durata limitata nel tempo. Il token era stato ottenuto dal client dopo aver fornito lo username e la password al server ad un endpoint di login. Anche questo è soggetto ad attacchi di tipo replay.
  • Http digest Il client invia una richiesta al server, che gli risponde con un errore 401 Unauthorized. Nella stessa risposta, invia anche il realm e un nonce, ovvero un codice monouso che il client dovrà usare nella sua prossima richiesta. A questo punto il client usa lo username, la password, il realm e il nonce per crearsi un hash che include in una nuova richiesta immediata. Il server, anch'esso in possesso di username e password, è in grando di ricalcolarsi l'hash e verificare che sia corretto. Se lo è, autorizza il client. Questo meccanismo di permette di non far viaggiare username e password con la richiesta e di impedire attacchi di tipo replay, dato che il nonce per definizione è usabile solo una volta. Non è necessario comunicare su HTTPS ma è sempre meglio farlo per proteggere le informazioni che gli utenti caricano nella propria area riservata.
  • Hawk. Simile al precedente ma il nonce è generato dal client che nella sua richiesta include anche un timestamp, in modo che il server possa verificare che la richiesta è fresca. Anch'esso quindi è relativamente protetto da attacchi di tipo replay. C'è un'implementazione per ASP.NET WebAPI qui.
    https://github.com/pcibraro/hawknet


Scegli tu quello che ti sembra più appropriato, tenendo anche in considerazione il tempo di sviluppo che è richiesto per integrare il meccanismo scelto con la tua applicazione.

ciao,
Moreno
Modificato da BrightSoul il 07 dicembre 2015 16.07 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.