Hai ragione a preoccuparti di creare un nuovo account utente solo per questa attività. Un approccio molto più semplice consiste nell'utilizzare una chiave di applicazione inserita nell'intestazione della richiesta. Poiché utilizzi certificati autofirmati, ciò mi porta a credere che si tratti di una soluzione una tantum e che non verrà ridimensionata a centinaia di client. Ecco i passaggi per farlo accadere.
AGGIORNAMENTO: questa soluzione alternativa non avrà alcun impatto sull'applicazione ospitata da IIS, poiché URL Rewrite elaborerà la richiesta prima dell'applicazione. Per eliminare immediatamente i tentativi falliti, aggiorna la sezione azione della regola Riscrivi dell'URL al seguente. Si noti che ciò causerà la mancata visualizzazione delle richieste non riuscite nei log di IIS.
<action type="AbortRequest" />
Installa riscrittura URL su IIS
Questo è un modulo Microsoft che non è installato di default e fornisce funzionalità simili a mod_rewrite.
link
Crea regola di riscrittura degli URL
Aggiungi la seguente regola al web.config per la tua applicazione. Cercherà un'intestazione di richiesta di AppAuthKey (che puoi modificare / personalizzare) e un valore di joshua (non distingue tra maiuscole e minuscole e dovrebbe essere qualcosa di più complesso). Se uno dei due non è presente, verrà restituito il 401.4.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
</conditions>
<action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Modifica comando arricciatura
Aggiorna il comando arricciatura per includere l'intestazione della richiesta come segue:
curl -H "AppAuthKey: joshua"
Nessuna necessità di un certificato client
L'utilizzo di questo metodo non richiede un certificato client. Normale SSL (dovrebbe essere TLS1.2) sarà sufficiente fino a quando utilizzi cifrari forti. Ulteriori informazioni a riguardo sono disponibili nella seguente pagina OWASP:
link
AGGIORNAMENTO # 2
@AlphaD evidenzia punti positivi relativi alle varie impostazioni dei criteri che è possibile utilizzare per limitare ulteriormente gli account. Vorrei raccomandare contro questo dato che va contro la gestione della configurazione. Adottare questo approccio introduce i requisiti di configurazione per il sistema che ospita l'applicazione web che potrebbe o meno influenzare altri servizi. Il metodo preferito è quello di progettare l'app Web per la portabilità in modo che sia necessario poco del sistema di hosting. Supponiamo che abbia senso evidenziare alcuni punti chiave sul motivo per cui è preferibile utilizzare una chiave di applicazione in questa istanza piuttosto che un account utente locale o di dominio su IIS.
Utente locale
Se l'utente è locale solo al server Web che ospita IIS, quell'account sarà in grado di autenticarsi su qualsiasi altro sito Web e / o servizio ospitato da quel server. Assicurati che le autorizzazioni su tutte le altre risorse siano esaminate perché, per impostazione predefinita, l'account sarà membro del gruppo locale "Utenti" che ha una larghezza sorprendentemente ampia. Inoltre questo account ha accesso in lettura sul file system (NTFS). Se un altro sito web non è configurato correttamente, questo utente potrebbe essere utilizzato per autenticare e leggere il suo contenuto. L'autenticazione tramite questo account molto probabilmente utilizzerà l'autenticazione di base, il che significa che le credenziali sono codificate Base64 (non crittografate) e inserite in ogni intestazione di richiesta. (Proprio come la mia raccomandazione di aggiungere un'intestazione di richiesta personalizzata per l'autenticazione.) Infine, l'utilizzo di account utente locali rende difficile la gestione del sistema. Quando si esegue la migrazione del sito Web a un nuovo server, è necessario creare un nuovo account con autorizzazioni aggiornate e con ambito appropriato. Quelle informazioni di accesso devono quindi essere aggiornate negli script di ricciolo consumante. Non rende la tua applicazione portatile.
Utente dominio
Come per l'utente locale, ora l'ambito in cui questo utente può autenticarsi è stato esteso all'intero dominio. Ciò include l'accesso in lettura a gran parte della directory attiva e di altri servizi pubblicizzati nell'ambiente. L'autenticazione con questo utente sarà un po 'più sicura poiché NTLM o Kerberos possono essere utilizzati a condizione che AD sia accessibile e che l'host Linux sia configurato per l'autenticazione AD. Altrimenti sarà probabilmente utilizzata l'autenticazione di base. La gestione degli account diventa un po 'più semplice poiché rientrerà nel dominio della gestione degli account di dominio invece della gestione degli account di sistema e spesso (non sempre) ci sono procedure consolidate per la gestione degli account di dominio.
Chiave dell'applicazione
Metodo preferito poiché non è richiesto alcun account utente e limita l'ambito solo a questa applicazione. Rendere il punto debole il canale di comunicazione (protetto tramite TLS e cifrari forti) e la directory dei contenuti che dovrebbe comunque avere accesso limitato.