3.8 Windows Azure platform
3.8.4 Windows azure AppFabric access control service
Windows azure appFabric access control service è un sistema di gestione dell’au-tenticazione e delle autorizzazioni basato su sicurezza claim-base. I sistemi di sicurezzaclaim-basepermettono di nascondere al servizio i dettagli di autenticazione e autorizzazioni degli utenti. Per fare ciò si va ad utilizzare un entità di fiducia (relyng parties). Il relyng parties riceve una richiesta da un client che vuole accedere al servizio e restituisce untokencontenente una o più claims. Unclaims è un asserzione rilasciata da un entità per un altra entità nella quale vengono inviate informazione relative all’utente che ha richiesto l’accesso, come la sua identità e le sue autorizzazioni. Tale informazioni vengono recapitate al servizio il quale ha modo di verificare la veridicità deltokene quindi autorizzare l’accesso da parte dell’utente.
In questo modo il servizio non deve più preoccuparsi della gestione degli utenti, che verrà invece affidata ad unidentity provider che verrà contattato dal relyng partiesal fine di acquisire le informazioni necessarie per la creazione deltoken. Windows azure appFabric access controlviene utilizzata daservice busper auten-ticare e autorizzare i client prima che essi possano collegarsi al relay service. la necessità di autenticazione per accedere al servizio può comunque essere disabilitata.
L’autenticazione diservice bus può essere eseguita da qualsiasi identity provider di cuiaccess control si fida. Sarà compito di quest’ultimo produrre un token e i rispettivi claim richiesti daservice busper la gestione delle autorizzazioni.
Access controlpuò essere collegato a diversientity providercontemporaneamente, andando di fatto ad agire come un’autorità centralizzato di controllo degli accessi.
Inoltre Access control mette a disposizione un proprio entity provider che può essere gestito tramite un apposita interfaccia messa a disposizione dallo stesso.
Service busè stato disegnato per l’integrazione con access control, e questo com-porta cheservice bus si aspetti dei precisi claimincapsulati neitoken prodotti da access control, questo vale sia per i client che per i servizi. i principali claim sono:
39 39 di 87
• listen: che permette di creare un listener che permetta di ‘‘ascoltare’’ i messaggi nel realy service;
• send: che permette di inviare messaggi nelrelay service;
• manage: che permette di gestire il namespacedel servizio.
Al momento della richiesta da parte di un client o di un servizio ad access control, che richiede l’invio delle credenziali, per effettuare l’autenticazione e/o ottenere autorizzazioni viene presa, da parte di quest’ultimo, una decisione su quali autor-izzazioni concedere. Tale scelta viene fatta in base al servizio al quale si tenta di accedere, e nel caso di valide credenziali, access controlemetterà il relativo token contente le autorizzazioni aservice bus. Al momento dell’emissioneaccess control va a firmare il token in modo che service bus possa appurare con certezza la sua provenienza. Quando un client manda un messaggio al relay serviceincapsulando insieme il token che certifica i permessi per eseguire quell’azione, service bus per ragioni di sicurezza elimina iltoken dal messaggio prima di reindirizzarlo al servizio.
La Figura 3.8 illustra tale comportamento.
Figura 3.8: Interazione tra access controle service bus
Capitolo 4
Descrizione del problema
Il problema che questo progetto si propone di risolvere riguarda la creazione di un sistema software in grado di esporre immagini catturate da una webcam a più client.
Si vuole che il servizio esponga immagini sotto forma di feed RSS, e che, per l’accesso allo stesso non sia richiesta autenticazione.
È inoltre richiesto che per l’esposizione ed il consumo dei dati non sia necessario compiere alcuna operazione di tipo sistemistico, anche su terminali protetti da dispositivi firewall, Nat, e proxy. È necessario che i dati esposti godano di un buon grado di sicurezza, evitando quindi ad esempio esposizioni in DMZ.
La soluzione deve tenere d’occhio anche l’aspetto economico, andando a prevedere un sistema software che minimizzi il TCO.
Ogni immagine esposta deve essere riconducibile alla data e all’ora in cui è stata catturata dalla webcam, inoltre le immagini devono rimanere raggiungibili anche a seguito della loro uscita dal feed, dovuta alla loro ‘‘vecchiaia’’, rimanendo reperibili fino a quando l’applicazione che le espone rimane in vita, evitando così problemi per i client che ne mantenessero un riferimento.
Il feed deve esporre immagini ordinate per data e ora andando sempre ad esporre l’immagine più aggiornata catturata dalla webcam.
L’applicazione che va ad esporre le immagini deve essere scalabile non risentendo quindi dell’aumento delle richieste eseguite da un elevato numero di client.
È necessario che l’indirizzo scelto per l’esposizione del feed RSS sia indipendente dalla locazione geografica della macchina ospitante l’applicazione che esegue l’esposizione delle immagini, e che tale indirizzo rimanga costante nel tempo.
L’applicazione che espone le immagini deve agire come un servizio, andando a permette un’interazione con i client e permettere richieste parametrizzate al fine di poter restituire una partizione dei dati in base alla singola richiesta.
Tale applicazione oltre ad esporre le immagini deve prevedere una finestra che mostri, sul dispositivo ospitante, un’anteprima delle immagini catturate dalla webcam. Per quanto riguarda l’interazione con la webcam è richiesta una finestra di configurazione della stessa, dove sia possibile selezionare quale dispositivo webcam utilizzare (nel caso di più dispositivi collegati) e la risoluzione dell’immagine (tra quelle supportate dalla webcam).
L’applicazione deve prevedere la possibilità di fermare e far ripartire l’acquisizione di immagine, e quindi l’esposizione senza che l’applicazione debba essere spenta e riavviata.
Le immagini esposte devono poter essere consumate principalmente da tre tipi di client:
• Feed Reader;
41
• Applicazione Desktop;
• Applicazione mobile.
Nel caso dei feed reader le immagini devono essere esposte in base alla data e all’ora a loro associata, devono essere visualizzate solo le più aggiornate, andando ad eseguire l’aggiunta continua dell’immagine più recente e l’eliminazione della più ‘‘anziana’’.
Per quanto riguarda il formato del feed è richiesto che venga usato il formato RSS 2.0 basato su standard XML.
L’applicazione desktop deve collezionare le immagini esposte dal servizio e renderle visualizzabili all’utente. È necessario che l’interazione con il servizio e il download dei dati non comporti rallentamenti, all’interfaccia utente.
Deve essere gestita la casistica in cui il servizio non risultasse disponibile prima o durante l’esecuzione. Si richiede che tale applicazione esponga due modalità di utilizzo: la prima che permette di navigare tra le immagini ottenute, la seconda in cui viene visualizzata sempre l’immagine più aggiornata.
L’applicazione mobile deve poter essere eseguita su dispositivi windows phone 7. Anch’essa deve collezionare le immagini ricevute dall’applicazione che le espone.
Anche in questo caso sono richiese due modalità di utilizzo: la prima che permetta la navigazione tra le immagini collezionate dall’applicazione, mentre la seconda che permetta di visualizzare l’immagine più recente ottenuta. L’interazione con l’applicazione che espone i dati ed il download degli stessi non deve comportare rallentamenti dell’interfaccia utente.
4.1 Analisi Requisiti
Di seguito vengono riportati i requisiti alla quale la soluzione al problema sopraesposto dovrà sottostare al fine di soddisfare le richieste che il problema stesso propone.
Sono stati rilevati 3 principali componenti:
• il servizio, il quale ha il compito di catturare ed esporre le immagini tramite un feed;
• il client Desktop, che ha il compito di consumare i dati esposti dal servizio da un computer desktop;
• il client Mobileche mostra le immagini esposte dal servizio su un dispositivo Windows phone 7.
I requisiti di seguito esposti sono divisi per componente, in quanto ogni componente risulta essere una applicazione distinta.