La gestione dellidentità digitale...©Natale Prampolini AIEA Roma 3 -11-04 2 La gestione dell’identità digitale: conclusioni-E’ un grosso lavoro, faticoso e difficilmente evitabile-Serve

© Natale Prampolini AIEA Roma 3-11-04 1

La gestione dell’identità digitale:analisi, progettazione e privacy

IngIng.. NataleNatale PrampoliniPrampolini

Business & Technology AdviserBusiness & Technology Adviser


La gestione dell’identità digitale:conclusioni

- E’ un grosso lavoro, faticoso e difficilmente evitabile

- Serve per sistemare le situazioni pregresse

- Aiuta a rispettare le normative

- Non esistono scorciatoie, nè prodotti che risolvono tutto


L'identità digitale: questa presentazione

NON E’

• La presentazione di un prodotto

• La presentazione di una soluzione

• Una lista di Best practices: non bastano 45’

E’

• Il risultato di esperienze sul campo

• Complessa ed eterogenea come l’argomento che tratta

• Contiene concetti rielaborati da produttori, società di consulenza, letteratura ed esperti del settore, a volte in contrasto tra loro

• Una serie di spunti per evitare errori già compiuti da altri


La gestione dell’identità digitale:dare il giusto accesso alla persona giusta al momento giusto

- Concetti base e definizioni

- Le fasi: Accesso, Identificazione, Autenticazione, Autorizzazione, Validazione e Sottoscrizione

- Riferimenti con Codice della Privacy (D.lgs. 196/03)

- Esempi per mercato

- Base dati: LDAP vs. RDBMS

- I prodotti commerciali, gli standard a supporto

- Come introdurre uno strato di Identità Digitale in un sistema informativo complesso


L'identità digitale: analogie con il mondo reale

REALE

• Accesso fisico: portineria

• Identificazione: Nome e Cognome

• Autenticazione: documento

• Autorizzazione: decisione in base ai privilegi associati

• Privilegi: in base al profilo, ruolo, caratteristiche

DIGITALE

• Accesso informatico: Login

• Identificazione: User-id

• Autenticazione: PWD• Autenticazione forte:

Documento elettronico

• Autorizzazione: decisione in base ai privilegi associati

• Privilegi: in base al profilo, ruolo, caratteristiche


Concetti dell'Identità (digitale)

AUTENTICAZIONE:Un livello di sicurezza

che garantisce lavalidità di una

rappresentazione dell'identità

? Govt issued (Drivers license, social security, Passport)

? Biometric (Fingerprint, Retinal Scan, DNA)

? Self-selected (PIN number, secret password)

CONCETTO DEFINIZIONE ESEMPIO

ATTRIBUTI:Dati, profili, preferenze di una persona (fisica o

giuridica) o di un dispositivo

? Personal consumer preferences (e.g., travel, entertainment, dining)

? Identity-specific histories (e.g., purchases, medical records, etc.)

? Device capabilities information (e.g., text-only, video, etc.)

IDENTITA’: Identificazione univoca di un elemento di un

gruppo (istanza di una classe) tramite i suoi

attributi

? Natale Prampolini detto Nani, nato a Roma il 23-11-1950, codice fiscale PRMNTL50S23H501A


VALIDAZIONE:Conferma della volontà

da parte di un terzo rispetto alle due parti

del contratto

? Notaio per passaggi di proprietà,volture, successioni

CONCETTO DEFINIZIONE ESEMPIO

SOTTOSCRIZIONE:Manifestazione di

volontà, quindi un atto probatorio

? Firma autografa? Firma su assegni? Testamento? Contratti? Ricevuta di carta di credito

La possibilità di fornire servizi /

prodotti in dase adun'identitàautenticata

? Services based on attributes (e.g,. Travel, entertainment, dining)

? Transaction consummation? Gradient levels of service (e.g.,

based on employee level)

AUTORIZZAZIONE:

Concetti dell'Identità (digitale)


Dalla parte dell’utente

• Multiple carte, di credito, di debito, di riconoscimento, tesserine magnetiche, ecc.

• Multipli login, con UserId e Pwd

Ogni volta che chiedete un’informazione, comprate su Internet, vi iscrivete ad un convegno vi chiedono: nome, cognome, indirizzo, telefono, fax, email, ecc.

(Comunque vi chiedono più dati di quanti strettamente necessari, e il codice sulla Privacy (196/03) sanziona questo comportamento, in quanto non conforme alla legge…)


Sistemi di riconoscimento


Dalla parte dell’amministratore di sistema

• Per ogni nuovo dipendente devo provvedere a:

h Tesserino per accessi e procedure del personaleh Desktop con UserId e Pwdh Account di mailh Accessi alle applicazioni generalih Accessi alle applicazioni specificheh Accesso da remoto/mobile?h Accessi da dispositivi non PC?h Niente altro?

• E se è un consulente / partner / temporaneo?• Unified User Management

• Provisioning, User Management, Deprovisioning


• Il trattamento di dati personali effettuato con strumenti elettronici è consentitosolo se sono adottate, nei modi previsti dal disciplinare tecnico contenuto nell’allegato B), le seguenti misure minime:

• a) autenticazione informatica;• b) adozione di procedure di gestione delle credenziali di autenticazione;• c) utilizzazione di un sistema di autorizzazione;• d) aggiornamento periodico dell’individuazione dell’ambito del trattamento

consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici;

• e) protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici;

• f) adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi;

• g) tenuta di un aggiornato documento programmatico sulla sicurezza;• h) adozione di tecniche di cifratura o di codici identificativi per determinati

trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari.

Codice 196/03 “Privacy”Art. 34 - Trattamenti con strumenti elettronici


• Sistema di autenticazione informatica

• 1. Il trattamento di dati personali con strumenti elettronici è consentito agli incaricati dotati di credenziali di autenticazione che consentano il superamento di una procedura di autenticazione relativa a uno specifico trattamento o a un insieme di trattamenti.

• 2. Le credenziali di autenticazione consistono in un codice per l’identificazione dell’incaricato associato a una parola chiave riservata conosciuta solamente dal medesimo oppure in un dispositivo di autenticazione in possesso e uso esclusivo dell’incaricato, eventualmente associato a un codice identificativo o a una parola chiave, oppure in una caratteristica biometrica dell’incaricato, eventualmente associata a un codice identificativo o a una parola chiave.

• 3. Ad ogni incaricato sono assegnate o associate individualmente una o più credenziali per l’autenticazione.

• 4. Con le istruzioni impartite agli incaricati è prescritto di adottare le necessarie cautele per assicurare la segretezza della componente riservata della credenziale e la diligente custodia dei dispositivi in possesso ed uso esclusivo dell’incaricato.

• 5. La parola chiave, quando è prevista dal sistema di autenticazione, è composta da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito; essa non contiene riferimenti agevolmente riconducibili all’incaricato ed è modificata da quest’ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi. In caso di trattamento di dati sensibili e di dati giudiziari la parola chiave è modificata almeno ogni tre mesi.

Codice 196/03 “Privacy” Allegato Bdisciplinare tecnico in materia di misure minime di sicurezza


• Sistema di autenticazione informatica (continua)

• 6. Il codice per l’identificazione, laddove utilizzato, non può essere assegnato ad altri incaricati, neppure in tempi diversi.

• 7. Le credenziali di autenticazione non utilizzate da almeno sei mesi sono disattivate, salvo quelle preventivamente autorizzate per soli scopi di gestione tecnica.

• 8. Le credenziali sono disattivate anche in caso di perdita della qualità che consente all’incaricato l’accesso ai dati personali.

• 9. Sono impartite istruzioni agli incaricati per non lasciare incustodito e accessibile lo strumento elettronico durante una sessione di trattamento.

• 10. Quando l’accesso ai dati e agli strumenti elettronici è consentito esclusivamente mediante uso della componente riservata della credenziale per l’autenticazione, sono impartite idonee e preventive disposizioni scritte volte a individuare chiaramente le modalità con le quali il titolare può assicurare la disponibilità di dati o strumenti elettronici in caso di prolungata assenza o impedimento dell’incaricato che renda indispensabile e indifferibile intervenire per esclusive necessità di operatività e di sicurezza del sistema. In tal caso la custodia delle copie delle credenziali èorganizzata garantendo la relativa segretezza e individuando preventivamente per iscritto i soggetti incaricati della loro custodia, i quali devono informare tempestivamente l’incaricato dell’intervento effettuato.

• 11. Le disposizioni sul sistema di autenticazione di cui ai precedenti punti e quelle sul sistema di autorizzazione non si applicano ai trattamenti dei dati personali destinati alla diffusione.



• Sistema di autorizzazione

• 12. Quando per gli incaricati sono individuati profili di autorizzazione di ambito diverso è utilizzato un• sistema di autorizzazione.• 13. I profili di autorizzazione, per ciascun incaricato o per classi omogenee di incaricati, sono

individuati e configurati anteriormente all’inizio del trattamento, in modo da limitare l’accesso ai soli dati necessari per effettuare le operazioni di trattamento.

• 14. Periodicamente, e comunque almeno annualmente, è verificata la sussistenza delle condizioni per la conservazione dei profili di autorizzazione.

• Altre misure di sicurezza

• 15. Nell’ambito dell’aggiornamento periodico con cadenza almeno annuale dell’individuazione dell’ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici, la lista degli incaricati può essere redatta anche per classi omogenee di incarico e dei relativi profili di autorizzazione.



Enterprise Identity Infrastructure

The demand for reusable identity information is high

h Applications and databases maintain accounts and customer records

h Security and regulatory compliance require identity information

• Directory services are just the starting point

h Enterprise identity architecture requires use of meta-directory, virtual directory, user administration, and federation products

• These are not plug-n-play components, however

h Architects must understand what each is used for and plan create an appropriate architecture

h Interoperability is not assured

• Use a combination of products and technologies to create a strong identity infrastructure


Directories: Foundation for Identity

• Directories are still the best option for identity reuse

• Data model is designed for identity operations

h Good for rules/roles storage and calculation

h Managing relationships among entries

• Performance is optimized for identity

h LDAP provides straight-forward methods for using and describing information about groups, relationships, entry/attribute pairing

h Simple, dynamic replication for distribution and horizontal scale

• Lots of applications rely on LDAP

• Directories don’t deliver all the features, however

h LDAP directories are necessary but not sufficient for creating reusable identity infrastructure

h Architects need to think beyond the directory service àidentity service


Directories: Foundation for Identity• Defining the identity services layer

Authentication Access management User management

Identity access layer

PKI / other /specialized

Web access mgmt. Provisioning Identity andpolicy admin.

Directory repositories Meta-directoryVirtual directory /federation


Drafting an Architecture for Identity• Putting the pieces together


Drafting an Architecture for Identity

• Identity infrastructure toolbox

• Access layer and proxy servicesh Including federation standards and systems

• Virtual directoryh Link accounts and retrieve data directly from sources

• Meta-directoriesh Link accounts and synchronize attributes

• Provisioning systemsh Manage accounts as a business process

• LDAP directory servicesh Profile storage, authentication, defining relationships

• Identity and policy administration tools


Introduction

LDAPdirectories

Messag-ing

PBX / CTIVoIP

Identity-basedcompany access

Advanced businessinfrastructure

Basic businessinfra-structure

Enabling technology network/basic network infrastructure (network, servers, routers, OS, transport services)

Security/PKI

Manage-ment

Objectservices

Data-bases

Webservices

businessprocess

integrationMeta Directory services

Identit

ymana

gement

Acces

s/aut

horiza

tionAu

thentic

ation

Resourc

e pro

vision

ing

businessapplications

Process integration is just as important as the technology

Remote

employees

Legal/p

ublic

authoritie

s

EmployeesSuppliers

Partners

Customers


Making it happen: products and vendors• Identity market vendor consolidation

MetamergeMetamerge

BaltimoreBaltimore

InnosoftInnosoft

PhaosPhaos

Business LayersBusiness Layers

IBMIBM

DASCOMDASCOMAccess360Access360

NetegrityNetegrity

WavesetWaveset

TruLogicaTruLogica

HPHP

Sun OracleOracle

NetScreenNetScreen

NeoterisNeoteris JuniperJuniper


Making it happen: products and vendors

Vendors of identity infrastructure products

üütoolkitCalendra

ü & proxytoolkitSymlabs

üüin dev.Oblix

ü

ü

üKerberos

ü

üFederation

üOctetString

CalendraüüCritical Path

üüüNovell

üsomeRadiant

üembeddedüüSunüüüSiemens

üüüMaXwareüNetscapeHP

BizTalküüMicrosoftüüüIBM

üüüCAWorkflowVirtual-DirSynchDirectory



• Recommendations

• Create an architecture for identity servicesh Make use of the identity infrastructure tools now availableh Define an access layer that abstracts product-specificity from

internal developersh Include plans for management and administration of identity

servicesh Some pieces may not be needed

– Virtual directory, federation, and proxy are not always required at the identity service level

• Consider component integration during product selectionh How will pieces fit together to create a holistic solution?h Rely on a strategic / primary vendor with partnerships for missing

pieces



• Conclusion

• Identity services are mandatoryh Applications, infrastructure, and and regulations require accurate

identity information

• Directory services are necessary, but not sufficienth Several other products must be used in combination with directory

services to meet the requirements of the identity serviceh Architects need to plan the deployment, because the products

aren’t well integrated

• The identity service includes features fromh Directory, meta-directory, provisioning, directory proxy, virtual

directory, and administration productsh An access layer, which may require some custom development


Introduction• Start small and build upon your experience

• Infrastructure services must leverage the preceding technologies

• Most organizations have at least developed their directory and underlying network and application infrastructures

• Identity infrastructures are the fastest growing area of the marketplace

• Federation is rapidly increasing (5-10% of the Global 2000)

Othertechnologies

Directory Identity Federation

95-100%70-80% 20-30% 5-10%

Organizational deployment


Cost Savings

• Technologies: Directory services benefits (cont.)


Linkage of Trust Domains

.com .com

.com.com

.com.com

.com .com

.com.com

.com.com.com .com

.com.com

.com.com

Bank ATMNetwork A

Bank ATMNetwork B

Bank ATMNetwork C

Bank AATM Card

Bank BATM Card

Bank CATM Card

Individual Accounts with Many Web Sites

.com

.com

.com

Bank AATM Card

Bank BATM Card

Bank CATM Card

Federated Accounts within Trust Domain

.com

.com

.com

.com

.com

.com

Bank ATMNetwork A

Bank ATMNetwork B

Bank ATMNetwork C

Identità FederataSoluzione Analoga alle reti ATM

Separate Cards with Each Bank

Linked Cards within Bank Networks

Seamless Access Across all Networks


Examples of Trust Domains

Treasury Debt

EquityCommercialBanking

CreditClearingHouse

B2B – Financial Services

Suppliers Dealers

TransportAgencies

Manufacturers

FinancingFleet

B2B - Automotive

Car Rental

Hotel

PartnerAirlines

Airline

TrainCruiseLine

B2C – Travel Industry401k 3d Party

Providers

EmployeePurchase

Plans

DentalInsurance

Health Insurance

CompanyIntranet

B2E – EmployeeIntranet


Esempio per le Assicurazioni: la Gestione Sinistri

• Nel ramo danni, in molti casi va valutato il danno.

• Il flusso di lavoro prevede:

• notizia del sinistro da parte del cliente all’agenzia e da questa all’assicurazione

• stima da parte dell’ispettore (dipendente dell’assicurazione)

• valutazione da parte del perito (consulente esterno)

• proposta da parte dell’ispettore

• accettazione dell’indennizzo da parte del cliente

• erogazione da parte dell’assicurazione


Esempio di Telco Mobile

• Accesso

• via HTTP, punto fisso

• via telefono mobile

• via portale di un partner• Identità

• Se avete un telefono mobile, nota

• Se il telefono mobile è acceso, georeferenziato

• se via HTTP, come verificare verso il telefono mobile?


Esempio di Telco Mobile

• Autenticazione

• via HTTP, userid e pwd

• via telefono mobile, implicita

• via partner portal: da richiedere

• Autorizzazione

• Verso i miei servizi: facile, basso rischio

• Verso i servizi del partner, non è un mio problema

• Verso i servizi del partne: rischio medio-alto

• Serve un'autorizzazione maggiore


Il controllo accessi

• User Based: va bene solo per piccole organizzazioni, diventa velocemente troppo complesso da gestire

• Rule Based: va bene anche per grandi organizzazioni, ma bisogna definire tutte le regole, e verificarle ad ogni accesso

• Role Based: va bene solo per organizzazioni strutturate, con ruoli e processi ben definiti. Rappresenta, se ben progettato, un metodo molto efficiente.


Enterprise Directory Server

• Fondamenti di progettazione

• Il DIT sta al directory come lo schema entità-relazione sta agliRDBMS

• Gli oggetti (object classes) stanno al Directory come lo schema relazionale sta agli RDBMS.

• Gli indici e gli atttributi stanno al Directory come all'RDBMS• L’LDAP sta al directory come lo SQL sta agli RDBMS

Problema di provisioningdei dati

Implementazione della fase di progettazione


Protocollo LDAP – Functional model

Operazioni di interrogazione:

search, compare

Operazioni di Autenticazione e di Controllo

bind, unbind, abandon

Operazioni di modifica:

add, delete, modify, modify DN (rename)

LDAP definisce nove funzioni/azioni base:


Gruppi Statici

• I gruppi statici hanno un attributo chiamato uniqueMember con un valore fissato al DN per ogni membro del gruppo

• Vanno bene per gruppi di piccole dimensioni

• Non scalano bene• Una modifica richiede la riscrittura dell'intera entry

• Molte operazioni di update se il DN cambia o se la entry viene rimossa

• Ogni entry deve essere letta dall'interfaccia di gestione

dn: cn=Baseball Fans,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamescn: Baseball FansuniqueMember: uid=rwilson,ou=People,dc=siroe,dc=comuniqueMember: uid=scarter,ou=People,dc=siroe,dc=com

dn: cn=Baseball Fans,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamescn: Baseball FansuniqueMember: uid=rwilson,ou=People,dc=siroe,dc=comuniqueMember: uid=scarter,ou=People,dc=siroe,dc=com


Gruppi Dinamici

• Hanno un attributo chiamato memberURL, che, definendo le entry richiama una LDAP URL (una LDAP search)

• Le applicazioni devono compiere operazioni di read e searchutilizzando LDAP URL(s)

• Automaticamente valutate dal DS quando usati in ACI

• Scalano bene

dn: cn=Accounting Members,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamesobjectClass: groupofurlscn: Accounting MembersmemberURL: ldap:///dc=siroe,dc=com??sub?(&(objectclass=person)(ou=Accounting))

dn: cn=Accounting Members,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamesobjectClass: groupofurlscn: Accounting MembersmemberURL: ldap:///dc=siroe,dc=com??sub?(&(objectclass=person)(ou=Accounting))


Roles

• I “roles” sono un superset dei gruppi

• Le performance dei “ roles” sono state ottimizzate nel DS

• Assieme alle permission definiscono l’RBAC

• “Managed Roles” – simili ai gruppi statici

• “Filtered Roles” – simili ai gruppi dinamici

• “Nested Roles” – possono contenere altri “roles”

• I “roles” sono essenziali per una amministrazione cost-effective

• Una terminologia inconsistente ed una carenza di standard riguardanti i “roles-based access control” (RBAC) rallenta i miglioramenti e complica iconfronti tra prodotti


RBAC

elementi base• Gli utenti sono assegnati ai “roles”

• Le risorse hanno delle ”permissions” associate

• Le “permissions” per le risorse sono abbinate ai “roles”

• I “roles” permettono l'astrazione => efficienza, flessibilità, scalabilità

Users Roles Permissions Resources


“Roles” ed RBAC

Le definizioni e la gestione devono essere top-down• I processi di Business devono guidare e controllare i processi

tecnologici

• Nella e-economy e' fondamentale un appropriato controllo

Business Process Layer

Role Admin Layer

Access Control Layer

Roles

AssignmentsTo roles ONLY

Jobs


“Roles” ed RBAC Assegnazione dei ruoli

• Static: utilizza i gruppi, non scala, e' facile la delega, molte operazioni di update per spostamenti/terminations

• User: scala bene, difficile la delega, semplice la review degli user-role

• Dynamic: auto assegnazione, richiede ottimi processi e dati noncorrotti, utilizzato per provisioning ed accesso web

Static Assignment User AssignmentDynamic Assignment

JohnRoles:§ Manager§ EngineerAffiliation:§ EmployeeTitle:§ Engineering manager

Manager§ John§ Mary

Engineer§ John§ Bill

Employee§ Entries with

affiliation=‘Employee’

Groups

Manager§ Entries with ‘manager’

in their title


“Roles” ed RBAC -Value Proposition

Administrazione piu' facile, veloce e sicura• Meno lavoro – amministratori ed utenti piu' produttivi

• Users + permissions, invece di users x permissions• L'amministratore degli utenti non deve conoscere i processi di

business• Aggiunta e rimozione di “roles” senza modifica degli accessi • Richiesto meno skill nella normale amministrazione

• Meno assegnazioni favoriscono meno errori

La semplificazione riduce i costi• Permette automazione e riutilizzo di lavori già svolto• Riduce il numero degli amministratori e dello skill richiesto


“Roles” ed RBAC -Value Proposition

Facile scalabilità con la crescita• La gestione delle access control list (ACLs) non e'

scalabile

• Numero del rapporto users/permissions puo' crescerein maniera esponenziale e la gestione si complica

Miglior sicurezza• Separazione della gestione amministrativa

• Miglior monitoring ed auditing


Possibili scenari di introduzione di un IdM

• Directory Server• Directory Opaco

• Enterprise Directory Server

• Identity Server• SSO (Web Single Sign On, Reduced Sign On)

• Federation

• Portal Server• Web Application

• Legacy Application

• Gestione centralizzata• Delega di amministrazione

• Gestione applicativa


Directory Server

• Opaco• I prodotti di Identity Management prevedono la presenza di un

sistema di Directory Server.

• Tutti i prodotti hanno bisogno e usano un directory in modo nativo (mascheramento della Directory)

• Non è necessario prevedere attività sul Directory Server nel caso in cui la soluzione sia per SSO, o Unified user Management o Mail o Portal.

Nessuna attività prevista


Enterprise Directory Server

• Base fondativa dello Unified User Management

• In che modo è organizzata la base di utenza del sistema (perorganizzazioni aziendali, per canali, organizzazione alfabetica etc..)

• Le applicazioni aziendali devono essere LDAP enabled• Esiste un sistema di provisioning aziendale • La creazione dei dati è integrata con i processi aziendali

Attività di progettazione delloschema (DIT) e degli oggetti

Workshop di introduzione alloUnified User Management


Identity Management

• Esiste gia' un sistema di Directory?

• Se la risposta è no --> vedi le slides precedenti• Se la risposta è si: cosa si deve proteggere? Come? È necessario

un sistema di SSO? E' solo un problema di accesso o anche di presentazione? Se a questa domanda la risposta è: Presentazione vai alle soluzioni con Portal Server

• Siamo nel caso di WebApplication?

• Se la risposta è si: i servizi da proteggere sono identificabili condelle URI?

Linee guida di interoperabilià applicativaAnalisi applicazioni enterprise


Identity Management• Lo sponsor del progetto puo' far leva sugli owner delle

applicazioni?• Se la risposta è no --> rischio altissimo• Se la risposta è si: si deve prevedere un tavolo di assessment

applicativo (con sviluppatori)

• E' possibile avere al tavolo di assessment anche il responsabile della sicurezza?

• Se la risposta è no: esiste una tabella che lega la criticità dei processi alla criticità dei dati?

• Se la risposta è si: ricordare che non si tratta di sicurezza perimetrale?

Specifiche


Portal Server• E' possibile dividere le applicazioni in Web e Legacy?• Le applicazioni legacy prevedono un client apposito?

Esiste?• I contenuti sono tutti già collocati in azienda?

• Il sistema di Portal dovrà organizzare l'accesso alle applicazioni o anche fornire i meccanismi di visualizzazione dell'input e dell'output?

• L'autorizzazione funzionale rimane nelle applicazioni?

• Ci sono contenuti provenienti dall'esterno che vanno integrati?


Portal Server

• Il sistema di Mail Enterprise prevede la presenza delle Mailsul server?

• L'eventuale client di Mail Corporate prevede la possibilità di avere piu' profili?

• Chi si fa carico della integrazione applicativa con il sistema di Portal?

• Il cliente è consapevole che deve modificare le applicazioni?


Gestione User e Applicazioni

• La gestione utenti deve essere delegata?

• Ad Aziende del gruppo o in servizio di outsourcing?

• Che visibilità deve essere data dei dati dei singoli utenti?

• Le applicazioni devono essere integrate in un ambiente operativo esistente?

• Ci sono livelli di operatori diversi? (junior, senior)

• Con differenti livelli di responsabilità sulla suite?


Gestione User e Applicazioni:SAP Portal (50 057 993s (02/08s))


Gestione User e Applicazioni:Oracle Identity Management

• Oracle Indentity Management (OIM) è un’infrastruttura integrata per la gestione degli aspetti di sicurezza legati all’identificazione dell’utente.

• Gestione di un unico repository, LDAP v3 (Oracle Internet Directory)• Servizio di Autenticazione centralizzato Oracle Single SignOn Server• In più Oracle Directory Integration Platform (ODIP): al fine di ottenere un repository unico

degli utenti OID offre un insieme di API denominate Oracle Directory Integration Platform(ODIP) per garantire l’integrazione (master-slave e/o master-master) con altri repository

• OID• iPlanet Connector • Oracle HR Connector • Active Directory Connector

• OSSO• Web Server plug-in: Apache, Sun Web server, MS IIS• Application Server J2EE• IdM: Netegrity Siteminder ®, RSA ClearTrust, IBM Tivoli Access Manager• Login trasparente su Windows (Microsoft Kerberos• Supporto per i certificati e smartcard (Poste, Infocamere, CIE, CNS, Poste, BNL ecc)


Gestione User e Applicazioni:Black Box

• Ho un’applicazione funzionante, ma non la posso modificare (!!!)h Non ho i sorgenti, è troppo complesso/difficile, scade la garanzia, il

fornitore non vuole modificarla, ecc.

• Posso inserire uno strato in mezzo?

• Posso mettere un automa che simuli il login da parte dell’utente?

• Posso canalizzarla in una Portlet di un Portale?

• Probabilmente ho risolto il SSO, forse anche il Provisioning• Il Deprovisioning rimane da automatizzare


Linguaggi e standard:OASIS

• The Organization for the Advancement of Structured Information Standards

• www.oasis-open.org

• DSML: Directory Services Markup Language v2.0 December 18, 2001Approved as an OASIS Standard April 30,2002

• XACML: eXtensible Access Control Markup Language XACML 1.1 Specification Set (24 July 2003):

• XACML Profile for Role Based Access Control (RBAC): Committee Draft 01 (normative; 13 February 2004)

• SAML: Security Assertion Markup Language v1.1 August 2003

• WSS: Web Services Security v1.0 March 2004


Linguaggi e standard:Liberty Alliance

• www.projectliberty.org

• Liberty Alliance ID-FF 1.2 Specifications:Liberty Identity Federation Framework

• Liberty Alliance ID-WSF 1.0 Specifications:Liberty Identity Web Services Framework

• Liberty Alliance ID-SIS 1.0 Specifications:Liberty ID-SIS Personal Profile Service


Considerazioni finali

• Affidare la gestione dell'Identità Digitale ad un frameworkinfrastrutturale può aiutare a progettare e realizzare applicazioni dotate dei necessari gradi di sicurezza, riservatezza e semplicitàd'uso oggi richiesti.

• Utilizzare un framework di gestione dell'Identità Digitale può servire a concentrarsi sullo sviluppo della logica applicativa e realizzare moduli di funzioni che implementano servizi consistenti.

• E' necessario avere uno schema di progetto che evidenzi chiaramente le funzioni e i servizi richiesti al framework di gestione dell'Identità Digitale: solo in questo modo l'introduzione potrebbe avvenire con un impatto contenuto e con grande utilità nelle architetture attuali.


L'identità digitale

NaniNani PrampoliniPrampolini

[email protected]@ordine.ingegneri.vi.it

www.www.prampoliniprampolini.net.net

Domande Domande ??

Documents

La gestione dellidentità digitale...©Natale Prampolini AIEA Roma 3 -11-04 2 La gestione dell’identità digitale: conclusioni-E’ un grosso lavoro, faticoso e difficilmente evitabile-Serve