5 pagine in totale: <<Indietro 1 2 3 4 [5]
Con una funzione infine verificheremo le credenziali e autorizzeremo o meno l'utente.
Il risultato finale è il seguente:
<%@ Webservice class="TimeUtility" %>
Imports System
Imports System.DateTime
Imports System.Xml
Imports System.Web.Services
Imports System.Web.Services.Protocols
Public Class Authentication
Inherits SoapHeader
Public User as String
Public Password as String
End Class
<WebService(description:="Prova per l'identificazione dell'utente che utilizza i webservices",Namespace:="http://civi.no-ip.com/webservices/soapheader")> _
Public Class TimeUtility
Inherits Webservice
Public objAuthentication as Authentication
Private Function isAuthenticate()
if objAuthentication.User="Administrator" AndAlso _
objAuthentication.Password="12345" Then
return True
Else
Throw New SoapException("Access danied", New XmlQualifiedName("SoapHeader"))
return False
End If
End Function
<WebMethod(Description:="Restituisce l'ora attuale"), _
SoapHeader("objAuthentication", Required:=true)> _
Public Function WhatTimeIsIt() as String
if not isAuthenticate Then Exit Function
return Now().ToString
End Function
End ClassPassiamo quindi al client. Questa volta sarà necessario rigenerare il proxy.
Analizzandone il codice si noterà che è stata creata una nuova classe di nome Authentication oltre alla solita TimeUtility, esattamente la stessa che avevamo creato per definire le variabili da passare nell'header Soap.
Inoltre all'interno della nostra classe proxy ci sarà una variabile per rappresentare l'istanza della classe Authentication:
Public AuthenticationValue As AuthenticationGeneralmente, tools come wsdl o Visual Studio.Net chiamano la variabile con lo stesso nome della classe aggiungendo il suffisso "Value". Quindi non dovremo far altro che creare una nuova istanza della classe Authentication, specificare il nome utente e la password e assegnare la nuova istanza alla variabile AuthenticationValue del nostro proxy:
<%@ Page Language="vb" debug="true" %>
<%@ Import namespace="System.Web.Services.Protocols" %>
<%@ Assembly src="ora.vb" %>
<script runat="server">
Private Sub Page_Load(sender as Object, e as EventArgs)
Try
Dim objOra as New TimeUtility
Dim objAuthentication as New Authentication
objAuthentication.User="Administrator"
objAuthentication.Password="12345"
objOra.authenticationValue=objAuthentication
result.Text="Sono le: " &objOra.WhatTimeIsIt()
Catch err as SoapException
result.Text=Err.Message
End Try
End Sub
</script>
<asp:Label id="result" runat="server" /> Ecco il risultato:
E' importante ricordare che se possibile, è opportuno proteggere i dati utilizzando la crittografia, utilizzando Secure Sockets Layer su protocollo HTTPS, non solo per l'invio delle credenziali, ma anche per la trasmissione delle risposte dei web services, che possono contenere a volte dati sensibili o di notevole importanza.
Come fornitore, per utilizzare SSL occorre abilitarne l'uso nella nostra applicazione tramite IIS e validare il certificato tramite la funzione Request.ClientCertificate.IsValid.
Come client invece bisogna aver a disposizione un certificato valido che dovremo caricare tramite la classe System.Secuirity.Cryptography e assegnarlo alla proprietà ClientCertificates del nostro proxy. Si tratta di un argomento avanzato e che varia a seconda della crittografia utilizzata, che esula dallo scopo di questo articolo.
Conclusioni
Sono stati presentati diversi modi per autenticare i nostri web services. Non ce n'è uno migliore di un altro, perciò la scelta spetta in base al web services che usiamo e alla piattaforma su cui gira.
L'autenticazione Windows infatti non funzionerebbe, almeno per quando riguarda l'autenticazione NTLM, su webserver non IIS.
Quella che utilizza il Soap headers diventa una soluzione invece più standard utile anche nel caso in cui volessimo inviare dei dati in più oltre all'user e la password, cosa che le altre due forme di autenticazione non permettono.
L'autenticazione tramite forms invece non essendo una soluzione di uso comune ha il vantaggio di inviare le credenziali la prima volta e di usufruire dei cookies per le successive autenticazioni.
Non resta che provare e applicare queste basi per proteggere gli investimenti delle aziende.
Approfondimenti
5 pagine in totale: <<Indietro 1 2 3 4 [5]
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download
