Come proteggere e misurare i servizi Web che condividi con i tuoi partner commerciali?

Question

Sto cercando idee su come limitare l'accesso e registrare le chiamate per un'API che stiamo fornendo per i partner commerciali per interfacciare con la nostra applicazione Customer Care. Dovremmo creare nomi utente e password per i nostri partner esterni proprio come faremmo con i nostri dipendenti? Esiste un qualche tipo di snap-in per .Net in grado di gestire le restrizioni di accesso e la misurazione o dobbiamo eseguire il rollover?

Quali formati dobbiamo supportare? JSON è canonico o c'è qualcosa di nuovo là fuori che devo sapere?

Sono nuovo a fornire il software come servizio e mi piacerebbe qualche consiglio, incluso un progetto .Net open source che posso esaminare per suggerimenti.

EDIT: ora con la freschezza della taglia!

EDIT: aggiunta di contenuti per rispondere ad alcune domande

questo sarà un'API per i nostri partner da utilizzare per accedere alle nostre funzioni di servizio al cliente, come ad esempio la creazione di nuovi account, effettuare i pagamenti e altre funzionalità di gestione degli account.

Ho familiarità con PostSharp e ho già prodotto una demo di tecnologia con funzionalità di registrazione per chiamate di metodo.

Non sono interessato a esaminare i nostri partner per quali formati/protocolli preferirebbero, poiché uno dei requisiti è la possibilità di aggiungere nuovi partner senza il coinvolgimento dell'IT. Vorrei solo alcuni suggerimenti sulle migliori pratiche, in modo che lo stiamo facendo nel modo "giusto" e che possano essere conformi.

Answer 1

Abbiamo utilizzato 3scale. Permette di misurare e limitare l'accesso alla tua API.

Answer 2

Penso che sia necessario definire a cosa stai pensando esattamente.

Software-as-a-service significa che stai offrendo un software funzionante per gli utenti di lavorare su i propri dati mentre si utilizza il software proprio come uno strumento per manipolare tali dati. Qui, gli utenti di solito non sono interessati ai dati che potresti offrire (è inutile per loro). SaaS è solo una soluzione alternativa per loro. Potrebbero anche sviluppare/installare software per i loro bisogni localmente, nella loro rete, perché il loro interesse principale è nei loro dati e hanno solo bisogno di uno strumento per lavorarci.

In generale, con il software-as-a-service si gestiscono gli utenti attraverso i loro account. Un account ha un feature pack in cui definisce le funzioni disponibili, le virgolette per le risorse utilizzate e i diritti di accesso che definiscono cosa può e cosa non può essere fatto.

Quello che stai descrivendo è fondamentalmente un accesso esterno a i tuoi dati. Ha poco in comune con il concetto di SaaS. Ad esempio, i servizi di geolocalizzazione GeoIP hanno lo stesso problema, forniscono l'accesso al loro database ma ne monitorano l'utilizzo per utente (ad esempio, un account consente 1000 richieste di geolocalizzazione per un utente al mese).

Per capire che cosa funziona meglio per te è necessario decidere quale tipo di attività desideri consentire ai tuoi partner commerciali di condurre.

• fare vogliono semplicemente leggere i vostri dati? Se si tratta di un semplice consumo di dati, probabilmente si può ottenere un account utente di base con limiti di utilizzo. Suppongo che dalla tua domanda sul formato dati preferito, suppongo che questo sia il tuo caso.

• Intendono partecipare attivamente al processo del servizio clienti e aggiungere, eliminare, modificare o altrimenti elaborare i dati? In questo caso è necessario pensare al design del proprio sistema e progettare (se non c'è ancora) un sistema di utenti, gruppi, diritti di accesso e quote. Creerai account per i tuoi partner commerciali mentre definirai le attività consentite, i limiti di utilizzo ecc. Quindi dovrai aggiornare il tuo codice base per osservare questi parametri.

Per quanto riguarda il formato, penso che sia irrilevante per la discussione e un po 'troppo presto per pensare. Potresti chiedere ai tuoi partner cosa preferirebbero.

Answer 3

Non sei molto chiaro su chi sia un partner; o se si sta proteggendo l'accesso ai dati, limitando le chiamate API, o entrambi.

Quello che stai facendo è molto specifico per la tua attività. Supponendo che sia necessario proteggere i dati che i servizi forniscono accesso è necessario autenticare ciascun utente e proteggere il livello di trasporto. Per il primo è necessario avere nome utente e password o un token API univoco per gli utenti finali. Questo dovrebbe essere controllato ad ogni richiesta. La sicurezza del trasporto può essere abilitata utilizzando SSL se si utilizza HTTP per i propri servizi. In genere è più semplice abilitarlo a livello di server Web, non si menziona il fatto che si sta effettuando un hosting speciale di servizi Web.

Supponendo che questa sicurezza sia attiva, dovrebbe fornire una base per il controllo che è ciò che presumo tu intenda per le chiamate di registro. Il nome utente o il token API ti daranno un'idea di chi sta effettuando una chiamata che è fondamentale per il controllo. Quindi creare un elenco di dati che si desidera vedere una traccia di controllo. Chiedi a un utente aziendale se le informazioni registrate possono aiutarti ad affrontare le domande che hai (cosa ti sta spingendo ad aggiungere la registrazione).

Le prossime cose da considerare è dove deve andare il codice di registrazione (c'è un punto centrale? Si utilizza AOP per aggiungerlo?) E dove deve essere registrato il percorso di controllo. Ci sono strumenti come PostSharp che ti permettono di tessere il log attraverso la tua applicazione senza molte modifiche, ma prima di fare questo vedi se c'è un modo semplice per aggiungere una funzione di registro ad una posizione comune nella tua applicazione per "intercettare" le informazioni che ti servono .

Una volta che hai le mani sui dati devi salvarlo da qualche parte. È qui che le cose possono diventare interessanti. Dovrai capire le caratteristiche di prestazione della tua applicazione e quali sono le probabilità di utilizzo. In molte applicazioni è sufficiente accedere a un database, ma a volte questo sarà un problema di prestazioni. La registrazione su file di testo è OK per alcune persone, ma cosa succede se i dati devono essere correlati al database dell'utente? In tal caso è necessario un codice per elaborare i file di registro e importare i dati.

Prima di dedicare troppo tempo alla creazione di qualsiasi codice di registrazione, vale la pena guardare NLog, Log4Net e la Libreria aziendale logging block. Questi sono strumenti generici che potrebbero fornire una base migliore.

Se è necessario applicare le quote utente, è possibile considerare la velocità con cui è possibile elaborare il registro per determinare il numero di chiamate effettuate da un utente. Idealmente, ogni volta che elabori una richiesta in arrivo avresti lo stato attuale di un utente a portata di mano per poter restituire una risposta appropriata. Può essere uno sforzo aggiungere questa funzionalità nelle applicazioni esistenti e fornire l'infrastruttura per supportarla.

Se utilizzare REST, JSON, XML, SOAP ecc. Dipende molto dal pubblico. Utilizzeranno linguaggi come Ruby e Python per chiamare i servizi o utilizzeranno .NET? Se saranno principalmente.Gli utenti della rete potrebbero quindi non avere molto senso costruire interfacce puramente REST usando JSON poiché .NET rende SOAP molto facile. Dall'altra parte della scala, SOAP e XML succhiano se si utilizza JavaScript sul lato client. Ricorda solo che non c'è una risposta giusta senza ulteriori informazioni sui tuoi utenti. Generalmente JSON non è una panacea e XML non è sempre l'opzione peggiore.

Aggiornamento

io non sono interessato a rilievo nostri partner per i quali formati/protocolli avevano preferiscono, dal momento che uno dei requisiti è la possibilità di aggiungere nuovi partner senza il coinvolgimento IT . Avrei proprio come alcuni suggerimenti sulle migliori pratiche, in modo che stiamo facendo il modo "giusto" e possono essere conformi.

L'opzione più flessibile è probabilmente REST e XML. Questo ampiamente supportato dal momento che quasi tutte le piattaforme hanno uno stack HTTP. XML è probabilmente più flessibile di JSON per rappresentare i tuoi dati. Vorrei iniziare qui e tornare indietro in termini di supporto, magari aggiungendo JSON. Tuttavia questo non è quello che definirei un approccio incentrato sul cliente. Se questa è una caratteristica fondamentale di una piattaforma, dovresti davvero interessarti a ciò che vogliono i tuoi clienti. Ehi, anche se oggi fai un rapido sondaggio, avrai un punto di partenza più ragionevole. Se conosci qualche sviluppatore di partner potresti essere in grado di supporre ciò che preferirebbero dagli strumenti e dai linguaggi che usano (anche andando a guardare i loro annunci di lavoro potrebbe darti un'idea di se sono un .NET o Java negozio - lontano da un approccio scientifico però).

Answer 4

Per limitare l'accesso ai servizi Web, un'opzione consente di implementare un meccanismo di autenticazione personalizzato basato su intestazioni di sapone personalizzate. Non è molto complicato e non sacrificherai l'interoperabilità. Ci sono un sacco di articolo per fare questo sul web, ad esempio: Build Secure Web Services With SOAP Headers and Extensions, Authenticate .NET web service with custom SOAP Header, ecc

Oppure si potrebbe avere uno sguardo a WS-Security e la prossima WS-Autorizzazione a che fare con concetti come l'identificazione, l'autenticazione e l'autorizzazione (vedi An Overview of the WS-Security Framework). Ma in realtà, non conosco abbastanza bene lo stack di Microsoft Web Services per fornire preziosi suggerimenti.

Per quanto riguarda la registrazione delle chiamate, non vedo alcuna difficoltà particolare. Una volta implementato l'accesso limitato, scoprirai cosa registrare e dove.

Answer 5

Per attuare le limitazioni di accesso

• io vi suggerisco di implementare la propria strategia. Abbiamo un requisito simile precedente e abbiamo implementato l'approccio seguente

  • Primo livello: Nome utente e password devono essere forniti per ogni richiesta.
  • 2 ° livello: la chiave di sessione (GUID) deve essere passata con ogni richiesta.
  • 3 ° livello: autorizzazioni livello risorse: è necessario passare i codici chiave specifici per accedere alle risorse. Per raggiungere questo obiettivo è necessario mantenere il set di autorizzazioni per ciascun cliente rispetto a ciascun reso. Questo ti consente di limitare i clienti con l'accesso limitato.

  questo sarebbe qualcosa di simile ..

  if (base.IsUserValid(userObject)) 
  { 
  if (base.ValidateSession("sessionid")) 
  { 
      if (base.IsUserAuthorizedToAccessResource("resourcekey","ReadorWrite")) 
      {    
       //Grant Access 
      } 
      } 
  } 
  

• E vorrei suggerire di utilizzare i servizi basati su SOAP/XML se il cliente utilizza le tecnologie .NET. REST/JSON è la soluzione migliore per il cliente che utilizza altre tecnologie. Ma questo dipende completamente dalle esigenze del cliente.