You are currently browsing Luca Postacchini’s articles.

La gestione degli aspetti di Authentication, Authorization ed Accounting (AAA) riveste un’importanza fondamentale per la sicurezza sia delle applicazioni usate all’interno dell’azienda stessa che di quelle utilizzate per proporre servizi alla propria clientela.

Questo a maggiore ragione in questi ultimi anni in cui la legge sulla privacy ha introdotto ulteriori requisiti e spostato la sicurezza da un solo concetto di difesa per chi eroga un servizio ad un meccanismo di difesa di chi usa quel servizio e come tale è costretto a fornire dati sensibili.

Le attuali soluzioni di Identity Management che implementano le funzioni di AAA hanno risolto egregiamente gli aspetti di Autenticazione che, tramite il Single Sign-On, permettono inoltre di unificare e centralizzare il controllo e la profilazione degli utenti.

Questo non è vero per quanto riguarda l’Autorizzazione soprattutto se questa è intesa come gestione dell’entitlement (cosa un utente è abilitato a fare) di tipo totalmente centralizzata, fortemente granulare e con alto gradi di dinamicità.

Ad oggi molto spesso la gestione dell’entitlement è implementata all’interno della singola applicazione rendendo difficile, se non impossibile la gestione dell’Autorizzazione in una architettura orientata ai servizi, dove l’applicazione non conosce a priori il contesto nel quale il servizio che offre viene “consumato”.

Ma cosa si intende esattamente per Entitlement?

La parola entitlement, specialmente se tradotta dal dizionario, può significare cose diverse a persone diverse. In questo contesto, per entitlement si intende un insieme di privilegi che governano quello che l’utente di una applicazione è abilitato a fare.

Un entitlement è la relazione tra una risorse dell’applicazione (o in forma più astratta un oggetto di business) e l’insieme di utente/gruppo/ruolo, rappresentata secondo una struttura gerarchica.

ALES fig1

Gli entitlement:

  • sono soggetti ad una massima proliferazione;
  • necessitano di considerare diverse informazioni di contesto prima di effettuare una decisione;
  • devono essere consistenti all’interno dell’infrasttuttura e all’insieme delle applicazioni;
  • devono essere allineati con i sistemi di Identity Management;
  • devono evolvere indipendentemente dalle applicazioni e dai servizi;

Tuttavia….

ad oggi la maniera più comune di implementare gli entitlements è cablarli nel codice dell’applicazione!!!

Per rispondere a questa esigenza BEA ha sviluppato la soluzione BEA AquaLogic Enterprise Security che permette di esternalizzare, unificare e semplificare la gestione delle politiche di autorizzazione ovvero degli entitlement.

La figura seguente mostra un esempio di applicazione di trading. Questa applicazione può essere usata da differenti tipologie di utenti, ma solo gli utenti che sono traders possono fare operazioni di acquisto/vendita. Inoltre, i traders posso operare solo per gli specifici conti per i quali sono autorizzati e solo fino ad uno specifico importo per ogni definito per ogni conto.

ALES fig2

 

Come si può vedere nel secondo caso, la decisione è rimossa dall’applicazione e valuta a runtime dal motore di BEA AquaLogic Enteprise Security.

Utilizzando BEA AquaLogic Enterprise Security all’interno della propria infrastruttura si possono quindi definire le linee guida con cui devono essere sviluppate le applicazioni per quanto riguarda la funzionalità di gestione dell’Autorizzazione, ovvero:

  • nessuna policy cablata nel codice
  • nessuna policy dipendente da un file di configurazione
  • scrittura del codice uniforme verso un unico layer per la gestione della sicurezza

Come funziona AquaLogic Enteprise Security in dettaglio?
Al prossimo post…

All’inizio era la telefonia tradizionale con i suoi servizi voce in grado di mantenere in crescita le revenue dei vari operatori telefonici. Poi sono arrivati i servizi a valore aggiunto (VAS) e la continua ricerca della killer application, l’ “Applicazione” che avrebbe dovuto colmare la diminuizione dei profitti dei servizi voce e degli sms. Sono stati fatti diversi tentativi, gli operatori hanno iniziato a collaborare con alcuni partner selezionati, per fornire servizi alternativi. Tutto questo non ha funzionato, o solo in parte. La dimostrazione sono le continue pubblicità che si vedono in giro dove gli operatori insistono ancora su offerte di voce e SMS/MMS senza mai promuovere nulla di nuovo.Nel frattempo sono arrivati i vari Google, Skype, Youtube, SecondLife che stanno catalizzando l’attenzione degli utenti relegando i carrier a semplici fornitori di connettività. L’utente acquista un abbonamento flat (a breve anche su terminale mobile), ottiene il suo accesso internet e diventa un nodo della rete, libero di decidere cosa fare e con chi.Ed ancora, l’introduzione di applicazioni quali wikies e blogs hanno spostato il ruolo dell’utente che da singolo consumatore dei contenuti presenti su internet a produttore. Gli americani hanno coniato il termine “prosumer”.E’ nato così il social networking con i sui strumenti di condivisione delle informazioni , di tagging, bookmarking, blogging e tutte quelle forme di aggregazione che fanno parte ora di un fenomeno chiamato Web2.0.Ora lo scenario sta cambiando, gli operatori hanno smesso da tempo di cercare la killer application e stanno cercando di inseguire questa nuova onda di entusiasmo e soprattutto hanno realizzato che o si alleano o perdono la guerra.

Si cominciano a concretizzare i primi progetti di Service Exposure che consistono nel rendere disponibili le funzionalità della rete come servizi accessibile dall’esterno a disposizione di chiunque voglia realizzare applicazione composite (mashup networks).

Questo perchè, sul piano tecnologico, gli operatori hanno ancora diverse carte da giocare perchè una delle grosse limitazioni nei servizi offerti dalle varie “Google companies” è data dal fatto che l’utente è anonimo in quanto si presenta con un indirizzo internet o al più è l’utente virtuale che ha deciso di essere. L’applicazione Google puo’ al massimo lavorare sugli header HTTP o sui cookies per cercare di gestire in qualche modo l’utente.

Gli operatori invece sono in possesso di un insieme di informazioni pregiate sull’utente per la realizzazione di servizi innovativi in quanto sono “fisicamente connessi” con loro:

  • Location – hanno l’informazione su dove l’utente si trova a diverse granularità
  • Network – hanno l’informazione su quale rete sono attestati
  • Bandwidth – hanno l’informazione sulla banda disponibile per una specifica sessione
  • Presence – hanno l’informazione sul terminale che l’utente sta utizzando tra quelli a disposizione con la stessa identita

Questi sono solo alcuni esempi di informazioni che fino ad oggi hanno tenuto gelosamente all’interno delle proprie reti sia per questioni puramente tecnologiche sia soprattutto perchè considerate un loro valore da non condividere

Ma oggi più che mai gli operatori possono raccogliere la sfida del Web 2.0 mettendole a disposizione sotto forma di Web Services , API, Widget, Pagelet.

BEA Systems ha creato da tempo una famiglia i prodotti WebLogic Communication Platform proprio per rispondere a questa nuova esigenza offrendo agli operatori una serie di soluzioni che permettono in modo rapido, seguendo un approccio SOA, di “esporre la rete come servizio”.

Per ulteriori approfondimenti vedi il sito http://www.bea.com/wlcp/

Attenzione!

Questo sito non è piu' aggiornato. Vieni a trovarci sul nuovo Caffe' con BEA

Disclaimer

I post su questo blog rappresentano i pensieri personali dei singoli autori e non rappresentano le posizioni ufficiali di BEA Systems. Se scrivete commenti, essi saranno rivolti solo ai singoli autori e non a BEA Systems. Le immagini ed i filmati possono essere tratti da Internet: qualore violassero eventuali diritti di autore, segnalatelo subito a pfurini@bea.com.