Esiste un modo per limitare l'accesso a un servizio Web ASMX, ad es. la pagina asmx e il suo WSDL?

Question

Ho un servizio web C # .net a cui devo limitare l'accesso. Richiedo già ai miei consumatori di utilizzare un nome utente e una password per chiamare il servizio. Ma c'è un modo per limitare l'accesso all'effettiva pagina asmx e al WSDL? Dovrei limitare l'accesso al servizio web tramite nome utente / password e indirizzo IP. Se un utente non avesse le credenziali corrette, non vorrei che sapessero quali metodi web esistono nel servizio web.

Questo può essere fatto tramite IIS? So che posso limitare gli indirizzi IP tramite IIS, ma posso anche usare nomi utente / password?

Esiste un altro modo per farlo al di fuori di IIS, magari usando C # .net?

Answer 1

Bene, dato che è ASMX hai l'intero stack di runtime ASP.NET a tua disposizione.

Passaggio 1: gestione della risorsa tramite .config

Applica un tag <location> per le risorse che vuoi proteggere. Supponendo che sia un singolo file ASMX, puoi semplicemente fare quanto segue nel tuo web.config:

<location path="MyWebService.asmx">
    <system.web>
        <!-- resource specific options will go here -->
    </system.web>
</location>

Passaggio 2: autenticazione dei tuoi utenti

Devi decidere in che modo autenticare gli utenti. Esistono diversi modi per farlo e diversi standard di autenticazione che potresti sfruttare. Devi scegliere l'approccio più adatto a te.

Se ti trovi su una rete Intranet e stai utilizzando l'autenticazione di Windows, ti consiglio vivamente di sfruttarlo perché è davvero l'opzione più semplice per ottenere l'installazione. Tuttavia, se i tuoi servizi sono accessibili su Internet, l'autenticazione di Windows non è in realtà un'opzione e devi scegliere da uno standard web. Il più semplice di questi è Autenticazione di base , ma dovresti solo su SSL poiché il nome utente / password non sono crittografati (solo codificato base64). Il prossimo passo da ciò è Autenticazione digest che non richiede SSL perché il nome utente / la password sono inviato usando un hash MD5. Per il massimo puoi andare con SSL v3 dove emetti un certificato client specifico per ciascun utente del tuo API.

Ora, quale opzione selezioni per la sicurezza determina cos'altro deve essere fatto. Se scegli la sicurezza di Windows, è facile come aggiungere il seguente elemento all'elemento <system.web> che abbiamo iniziato nel passaggio n. 1:

<authentication mode="Windows" />

Il resto dei protocolli di sicurezza richiederà un po 'più di lavoro. ASP.NET non fornisce supporto intrinseco per Basic, Digest o SSL v3. Tecnicamente puoi sfruttare IIS per fare questo tipo di autenticazione per te, ma sarà sempre associato a un utente Windows. Se questa è un'opzione per te, lascia semplicemente l'elemento <authentication mode="Windows" /> e configura IIS di conseguenza. Se, tuttavia, questa non è un'opzione, o semplicemente perché non hai alcun controllo su IIS / ActiveDirectory o devi autenticarti su un database utente personalizzato, ciò significa che devi collegare un HttpModule personalizzato per fornire supporto per questa sicurezza protocolli.

Passaggio 3: protezione della risorsa

L'approccio più semplice per proteggere la risorsa è fondamentalmente dire: " non lasciare che nessuno che non abbia autenticato con successo in qualche modo " ;. Questo viene fatto utilizzando la seguente configurazione di autorizzazione:

<authorization>
    <deny users="?" />
</authorization>

Se si desidera consentire solo determinati utenti, è possibile modificare invece le seguenti operazioni:

<authorization>
    <deny users="*" />
    <allow users="jdoe, msmith" />
</authorization>

Un altro approccio è quello di definire ruoli (gruppi) e semplicemente bloccare la risorsa su un ruolo speciale in cui si inseriscono gli utenti a cui si desidera accedere alla risorsa.

<authorization>
    <deny users="*" />
    <allow roles="My Service Users" />
</authorization>

Questo si associa bene all'autenticazione di Windows perché puoi semplicemente impostare un gruppo Windows e lasciare che il tuo team MIS gestisca quali utenti sono in quel gruppo usando ActiveDirectory. Tuttavia, la funzione funziona anche bene per l'autenticazione non Windows, supponendo che l'implementazione della sicurezza che hai usato esponga i ruoli tramite la sua implementazione IPrincipal.

Answer 2

Due opzioni: crea un sito completamente diverso su una porta diversa con autorizzazioni bloccate. Questo ha il vantaggio di fornire una quantità di & Quot; sicurezza attraverso oscurità & Quot; (scherzo a metà ...) Oppure puoi aggiungere una nuova Applicazione sotto il tuo sito (stessa porta, percorso diverso), in un pool di app diverso e assegnare le autorizzazioni in questo modo.

In entrambi i casi, il tuo servizio web non sarà in grado di parlare con i vari ASP.NET " cose " come l'oggetto dell'applicazione (beh lo sarà, ma non sarà lo stesso). La distribuzione è solo leggermente più difficile: distribuire gli stessi file binari, ma includere solo un file del servizio Web.

Answer 3

Puoi autenticarti usando un HttpModule. SSL + BasicAuthentication dovrebbe fornire la migliore interoperabilità con altre catene di strumenti.

In HttpModule, hai accesso alla richiesta e puoi negare agli utenti non autenticati l'accesso solo alle richieste .asmx. E anche allora potresti lasciarli accedere al WSDL.

Answer 4

Aggiungi <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> alla sezione <httpHandlers> del file web.config

Answer 5

Non so quanto sia pratico per te, ma potresti prendere in considerazione l'aggiornamento a WCF. WCF è completamente retrocompatibile con i servizi Web ASMX e consente di controllare se il WSDL è esposto o meno definendo un endpoint MEX (scambio di metadati). Nessun endpoint MEX, nessun WSDL.

Answer 6

È possibile interrompere la visualizzazione di WSDL rimuovendo il protocollo di documentazione dall'elemento in Machine.config

Aggiornamento: Autenticazione dei servizi Web - best practice? Se i tuoi utenti hanno nomi utente / password puoi utilizzare l'autenticazione di base HTTP tramite HTTPS.

Puoi anche implementarlo in modo leggermente diverso. La prima chiamata al tuo servizio web dovrebbe essere il metodo di autenticazione. Il client esegue l'autenticazione e riceve un token di autenticazione. Questo token deve essere presentato a tutti gli altri metodi esposti dal tuo servizio web.