Specifiche tecniche per la compilazione e l'uso degli Attributi

Transcript

1 Specifiche tecniche per la compilazione e l'uso degli Attributi v Gennaio 2010 Raffaele Conte 1 e Maria Laura Mantovani 2 con i contributi di Robero Gaffuri 3, Francesco Malvezzi 4 e Giacomo Tenaglia 5 1 Istituto di Fisiologia Clinica, CNR, Pisa <raf@ifc.cnr.it> 2 GARR e Università di Modena e Reggio Emilia<marialaura.mantovani@garr.it> 3 Politecnico di Milano <roberto.gaffuri@ceda.polimi.it> 4 Università di Modena e Reggio Emilia <francesco.malvezzi@unimore.it> 5 CNR, Biblioteca Area della Ricerca di Bologna <giacomo.tenaglia@area.bo.cnr.it>

2 Revisioni Versione Data Autore Febbraio 2008 Versione iniziale 2,0 26 Gennaio 2010 Revisione generale del testo. Adeguamento della terminologia in funzione di Shibboleth 2.0. Inserimento identificativi (urn) in Attributi: definizione dei metadati e notazione. Modifica paragrafo Confidenzialità/Visibilità Riorganizzazione delle Appendici A e B con indicazioni su configurazione di Shibboleth adeguate alla versione 2.x ed esempi. Correzioni minori. Ra. C. 2

3 Introduzione Scopo di questo documento è la standardizzazione dell'uso degli attributi tra i Partecipanti alla La Federazione IDEM (Identity Management per l'accesso federato, di seguito Federazione ). La procedura riguarda la denominazione, la sintassi, la semantica e i possibili valori degli attributi che gli Identity Provider delle Organizzazioni con cui l'utente è affiliato (Organizzazioni di Appartenenza) devono rilasciare ai Fornitori di Servizi. Per comodità, gli Attributi sono definiti utilizzando schemi standard LDAP. Nel documento viene definito l'insieme base degli attributi necessari al funzionamento della Federazione. Non si esclude che nel tempo questo insieme possa essere esteso. In generale, un Fornitore di Servizi non avrà necessità di ricevere dall'organizzazione di appartenenza di un utente tutti gli attributi definiti in questo documento e, in particolare, in diversi casi non sarà necessario accedere ai suoi dati personali. Spetta comunque all'organizzazione il compito di trasferire solo quegli attributi che sono stati giudicati meritevoli di trasferimento (Attribute Filter Policy) in conformità alla legislazione vigente, gli accordi tra i Membri e la volontà dell'utente. La risorsa acceduta dovrebbe richiedere soltanto gli attributi necessari per decidere riguardo l'autorizzazione all'accesso. Nella tabella del capitolo Panoramica sugli attributi questi sono divisi in tre categorie: 1. attributi riguardanti le caratteristiche personali del soggetto; 2. attributi riguardanti le modalità per contattare il soggetto; 3. attributi di ausilio alla fase di autorizzazione ed eventualmente di accounting. Quasi tutti gli attributi costituiscono dati personali ai sensi del D.Lgs. 196/2003 Codice in materia di protezione dei dati personali pertanto il loro trattamento è soggetto alla normativa citata. Gli Attributi che hanno lo stato obbligatorio (edupersonscopedaffiliation e edupersontargetedid) non costituiscono dati personali, pertanto è richiesto che l'organizzazione di Appartenenza li fornisca sempre a tutti i Fornitori di Servizi. Su questi attributi è però opportuno fare delle precisazioni. Sebbene non si possano considerare come dati personali in senso stretto, non possono essere nemmeno considerati come dati anonimi. edupersonscopedaffiliation infatti, in particolari condizioni, potrebbe rivelare l'identità della persona. Ciò può accadere quando per il tipo di affiliazione indicata esistono pochi o un solo utente all'interno dell'organizzazione. Per edupersontargetedid invece, l'identità del- 3

4 l'utente a cui l'identificativo è associato presso il Fornitore del servizio, è mascherata fino a quando non vengono incrociati i log con il fornitore dell'identità (IdP). In questo caso di parla di pseudonomizzazione. Si ritiene che il Fornitore di Servizio nella maggior parte dei casi non abbia necessità di ulteriori dati, in particolare di quelli personali dell'utente; gli è sufficiente sapere che l'utente è registrato nella Federazione, eventualmente presso una certa Organizzazione (edupersonscopedaffiliation). In aggiunta può discriminare l'accesso in base al grado di affiliazione (sempre con eduperson- ScopedAffiliation). Può inoltre individuarlo univocamente (comunque in forma pseudo-anonima) per fornirgli un servizio personalizzato (edupersontargeted- ID). La Federazione ritiene che gli attributi qualificabili come dati personali dell utente siano meritevoli di protezione e dunque vadano comunicati solo in caso di necessità al fine dell erogazione del servizio. Se non strettamente necessario non devono venire scambiati attributi che rivelano l identità degli utenti. D'altra parte non si esclude che particolari servizi possano avere questa esigenza e per tale ragione alcuni attributi vengono indicati come raccomandati oppure opzionali. È a carico dell'organizzazione permettere ai propri utenti di scegliere se consentire il trasferimento di tali dati al Fornitore del Servizio.Per soddisfare tale volontà è possibile configurare l' Attribute Filter Policy di Shibboleth. È ovvio che nel caso in cui questi dati non siano resi disponibili, alcuni servizi potrebbero risultare non accessibili. L organizzazione di appartenenza resta comunque responsabile della protezione dei dati dei propri utenti. Panoramica sugli attributi Gli attributi selezionati provengono dall'insieme degli attributi di base definiti per il protocollo LDAPv3 [RFC4519] e dagli schemi Cosine [RFC4524], inet- OrgPerson [RFC2798], eduperson [EDUPER] e schac [SCHAC]. Ogni attributo prevede uno stato che può assumere uno fra i valori obbligatorio, raccomandato e opzionale. L'insieme degli attributi obbligatori costituisce quindi il set minimo per aderire alla Federazione. L'insieme degli attributi obbligatori costituisce quindi il set minimo per aderire alla federazione nell'ipotesi di preservare al massimo la riservatezza dell'utente. Sono considerati obbligatori i soli attributi edupersonscopedaffiliation ed edupersontargetedid che permettono al Service Provider di verificare l'affiliazione dell'utente all'interno dell'organizzazione di appartenenza ed avere un riferimento nel tempo dell'utente stesso in modo da costruire un eventuale ambiente e/o sessione pseudo-anonimi per gli accessi successivi. 4

5 Per gli scopi attuali della Federazione non sembra necessario indicare, almeno per ora, l'utilizzo di ulteriori attributi al di fuori di quelli descritti nel presente documento. Tuttavia gli Identity Provider (IdP) potrebbero avere necessità di utilizzare ulteriori attributi per scopi locali. Gli attributi elencati sono suddivisi per tipologia. Caratteristiche personali Nome LDAP Origine Stato sn LDAPv3 Cognome opzionale givenname LDAPv3 Nome opzionale cn LDAPv3 Nome seguito da Cognome raccomandato preferredlanguage inetorg- Person Lingua scritta o parlata preferita dal soggetto raccomandato schacmothertongue schac Lingua madre del soggetto opzionale title LDAPv3 Titolo nel contesto dell'organizzazione (es. "Direttore", "Responsabile Reparto X" ecc.) opzionale schacpersonaltitle schac Titolo usato per salutare il soggetto. Es: Sig., Sig.ra, Dott., Prof. opzionale schacpersonalposition schac Il codice rappresentativo dell'inquadramento della persona all'interno dell'organizzazione secondo le convenzioni descritte nell'appendice B opzionale Contatti Nome LDAP Origine Stato mail Cosine Indirizzo raccomandato telephonenumber LDAPv3 Recapito telefonico ufficio opzionale mobile Cosine Recapito cellulare di servizio opzionale facsimiletelephonenumber LDAPv3 Recapito fax opzionale schacuserpresenceid schac Recapiti relativi a diversi protocolli di rete opzionale edupersonorgdn eduperson Il Distinguished Name della entry che rappresenta l'organizzazione di appartenenza alla quale la persona è associata opzionale edupersonorgunitdn eduperson Il Distinguished Name della entry che rappresenta l'unità organizzativa di appartenenza alla quale la persona è associata (ad esempio Dipartimento) opzionale 5

6 Autorizzazioni e accounting Nome LDAP Origine Stato edupersonscopedaffiliation eduperson Affiliazione secondo le convenzioni descritte nell'appendice B obbligatorio edupersontargetedid eduperson Identificativi anonimi persistenti per l'utente relativi ai diversi Servizi obbligatorio edupersonprincipalname eduperson unico persistente dell'utente raccomandato edupersonentitlement eduperson URI (URN o URL) che indica un diritto (standardizzato) di accesso ad una risorsa raccomandato (se applicabile) Attributi Notazione Per tutti gli attributi sono definiti i seguenti meta-dati: : una breve descrizione dell attributo; : URN che identifica in maniera univoca l'attributo 6 ; : la semantica dell attributo; Riferimenti: standard di riferimento; Sintassi LDAP: La sintassi LDAP dell'attributo (si veda [RFC2252]); # di valori: singolo o multiplo; Valori permessi: una lista di valori permessi: dove possibile basata su standard nazionali o internazionali; : obbligatorio: un IdP deve fornire questo attributo per poter fare parte della federazione; raccomandato: è fortemente raccomandato che un IdP fornisca questo attributo; opzionale: alcuni SP potrebbero richiedere questo attributo; Note: informazioni aggiuntive relative all'attributo; Esempi: esempi nel formato LDIF ([RFC2849]); 6 L'URN è necessario nella configurazione di Shibboleth. Nella versione 2.x, in base alle indicazioni di SAML 2.0, la notazione usata è urn:oid, ma per compatibilità verso i partner 1.3 l'attributo è definito anche con la notazione testuale (ad es.: urn:mace:dir:attribute-def:sn) 6

7 : autorizzazione: un SP usa questo attributo per prendere decisioni relative all'accesso alla risorsa; accounting: questo attributo è usato per motivi legati all'accounting; informazioni aggiuntivi sull utente: informazioni che non sono tipicamente usate per autorizzazione o accounting ma possono servire per offrire un miglior servizio all'utente (ad esempio: nome e cognome da usare in un portale personalizzato); AAI internal: usato per scopi interni alla Federazione; l'attributo non è accessibile dalla risorsa; Definizione dei metadati Caratteristiche Personali Questo gruppo di attributi può essere trasmesso dall organizzazione di appartenenza a determinati Fornitori di Servizio con i quali è stata valutata l utilità dei valori trasmessi ai fini della fornitura del servizio stesso. Tipicamente tali attributi vengono esclusivamente utilizzati per chiamare l utente per nome. Salvo rari e motivati casi, non devono mai essere usati per determinare il diritto di accesso al servizio. sn Riferimenti Cognome urn:mace:dir:attribute-def:sn urn:oid: Cognome della persona come usato nelle comunicazioni ufficiali [RFC4519] Sintassi LDAP Directory String Valori permessi Note Esempi singolo n/d opzionale La definizione di sn in [RFC4519] prevederebbe una molteplicità di valori per questo attributo al fine di accelerare le ricerche per la maggior parte dei client LDAP. Tuttavia all'interno della Federazione, l'organizzazione di appartenenza deve fornire un solo valore, ossia quello utilizzato per le comunicazioni ufficiali con la persona. sn: Rossi 7

8 Informazioni aggiuntive sull'utente givenname Riferimenti Nome urn:mace:dir:attribute-def:givenname urn:oid: Nome proprio della persona come usato nelle comunicazioni ufficiali [RFC4519] Sintassi LDAP Directory String Valori permessi Note Esempi singolo n/d opzionale La definizione di givenname in [RFC4519] prevedrebbe una molteplicità di valori per questo attributo al fine di accelerare le ricerche per la maggior parte dei client LDAP. Tuttavia all'interno della Federazione, l'organizzazione di appartenenza deve fornire un solo valore, ossia quello utilizzato per le comunicazioni ufficiali con la persona. givenname: Andrea Informazioni aggiuntive sull'utente cn Riferimenti CommonName urn:mace:dir:attribute-def:cn urn:oid: Nome completo della persona [RFC4519] Sintassi LDAP Directory String Valori permessi Note Esempi singolo n/d raccomandato La definizione di cn in [RFC4519] prevedrebbe una molteplicità di valori per questo attributo al fine di accelerare le ricerche per la maggior parte dei client LDAP. Tuttavia all'interno della Federazione, l'organizzazione di appartenenza deve fornire un solo valore, ossia quello utilizzato per le comunicazioni ufficiali con la persona. cn: Andrea Rossi Informazioni aggiuntive sull'utente 8

9 preferredlanguage Lingua preferita dall'utente urn:mace:dir:attribute-def:preferredlanguage urn:oid: Lingua scritta o parlata preferita dall'utente Riferimenti [RFC1766], ISO 639 ISO 3166 Sintassi LDAP Directory String Valori permessi Esempi singolo I language-tag sono formati da un primary-tag e da più subtag Questi ultimi posso anche essere vuoti. language-tag = primary-tag *( "-" subtag) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Non sono consentiti spazi bianchi tra i tag. I tag non sono case sensitive. I name space dei language-tag sono amministrati da IANA. raccomandato preferredlanguage: it preferredlanguage: it-ch Informazioni aggiuntive sull'utente schacmothertongue Riferimenti Lingua madre dell'utente uurn:mace:terena.org:attribute-def:schacmothertongue urn:oid: È la prima lingua che una persona impara ISO 639, [RFC3066] Sintassi LDAP Directory String Valori permessi Esempi singolo Come sopra raccomandato schacmothertongue: it schacmothertongue: fr-ch Informazioni aggiuntive sull'utente title Titolo della persona nel contesto dell'organizzazione urn:mace:dir:attribute-def:title urn:oid:

10 Il titolo di una persona nel contesto della propria organizzazione Riferimenti [RFC4519] Sintassi LDAP Directory String multiplo Valori permessi n/d opzionale Esempi title: Direttore Informazioni aggiuntive sull'utente schacpersonaltitle Riferimenti Titolo usato per salutare il soggetto urn:mace:terena.org:attribute-def:schacpersonaltitle urn:oid: Il titolo personale dell'utente [RFC1274] Sintassi LDAP Directory String Valori permessi Esempi singolo n/d opzionale schacpersonaltitle: Sig. Informazioni aggiuntive sull'utente schacpersonalposition Il codice rappresentativo dell'inquadramento della persona all'interno dell'organizzazione urn:mace:terena.org:attribute-def:schacpersonalposition urn:oid: Si veda l'appendice B Riferimenti SCHAC-IAD Version Sintassi LDAP Directory String # di valori multiplo Valori permessi Si veda l'appendice B opzionale Esempi schacpersonalposition: PO, PA, RU,... Informazioni aggiuntive sull'utente 10

11 Contatti Questo gruppo di attributi può essere trasmesso dall organizzazione di appartenenza a determinati Fornitori di Servizi con i quali è stata valutata l utilità ai fini della fornitura del servizio stesso. Tipicamente tali attributi vengono utilizzati per contattare personalmente l utente al fine di fornirgli il servizio o parte di esso mediante strumenti diversi dal web. Non devono mai essere usati per determinare il diritto di accesso al servizio. mail Riferimenti Indirizzo urn:mace:dir:attribute-def:mail urn:oid: La casella di posta elettronica dell'utente [RFC4524] Sintassi LDAP IA5 String Valori permessi Note Esempi multiplo n/d raccomandato I valori dovrebbero essere editabili dall'utente stesso mail: andrea.rossi@unimi.it Informazioni aggiuntive sull'utente telephonenumber Riferimenti Recapito telefonico urn:mace:dir:attribute-def:telephonenumber urn:oid: Numero di telefono dell'utente, indicato in accordo al formato internazionale dei numeri di telefono [RFC4519] Sintassi LDAP Telephone Number Valori permessi Note multiplo n/d opzionale Particolari servizi potrebbero voler contattare l'utente al telefono. Occorre fare attenzione alla privacy dell'utente quando si trasferiscono numeri telefonici privati. Non ci dovrebbero essere problemi nel trasferimento di numeri telefo- 11

12 nici di servizio. I valori dovrebbero essere editabili dall'utente stesso Esempi telephonenumber: Informazioni aggiuntive sull'utente facsimiletelephonenumber Riferimenti Recapito fax urn:mace:dir:attribute-def:facsimiletelephonenumber urn:oid: Numero di fax dell'utente, indicato in accordo al formato internazionale dei numeri di telefono [RFC4519] Sintassi LDAP facsimile Telephone Number Valori permessi Note multiplo n/d opzionale Particolari servizi potrebbero voler contattare l'utente via fax. Occorre fare attenzione alla privacy dell'utente quando si trasferiscono numeri telefonici privati. Non ci dovrebbero essere problemi nel trasferimento di numeri telefonici di servizio. I valori dovrebbero essere editabili dall'utente stesso Esempi facsimiletelephonenumber: Informazioni aggiuntive sull'utente mobile Riferimenti Recapito cellulare urn:mace:dir:attribute-def:mobile urn:oid: Il numero di cellulare associato all'utente, indicato in accordo al formato internazionale dei numeri di telefono [RFC4524] Sintassi LDAP Telephone Number Valori permessi n/d Note multiplo opzionale Particolari servizi potrebbero voler contattare l'utente al telefono via voce oppure via SMS. Occorre fare attenzione alla privacy dell'utente quando si trasferiscono numeri telefonici privati. Non ci dovrebbero essere problemi nel trasferimento di numeri telefonici di servizio. I valori dovrebbero essere editabili dall'utente stesso Esempi mobile: Informazioni aggiuntive sull'utente 12

13 schacuserpresenceid Riferimenti Insieme di recapiti relativi alla presenza della persona in rete urn:mace:terena.org:attribute-def:schacuserpresenceid urn:oid: Recapiti relativi a diversi protocolli in rete Sintassi LDAP Directory String Valori permessi n/d Note Esempi multiplo opzionale I valori dovrebbero essere editabili dall'utente stesso schacuserpresenceid = xmpp:a.rossi@unimi.it schacuserpresenceid = sip:rossi@myweb.com schacuserpresenceid = sip: @unimi.it;transport=tcp;user=phone schacuserpresenceid = sips:alice@atlanta.com?subject=project %20x&priority=urgent schacuserpresenceid = h323:andy@myweb.it:808;params schacuserpresenceid = skype:andrea.rossi Informazioni aggiuntive sull'utente edupersonorgdn Riferimenti Il Distinguished Name della entry che rappresenta l'organizzazione di appartenenza alla quale la persona è associata urn:mace:dir:attribute-def:edupersonorgdn urn:oid: eduperson2006 Sintassi LDAP Distinguished Name syntax Valori permessi n/d Esempi singolo opzionale EduPersonOrgDN: o=dipartimento di Chimica,dc=unimore, dc=it EduPersonOrgDN: dc=ifc,dc=cnr,dc=it EduPersonOrgDN: o=istituto di Fisiologia Clinica,dc=ifc,dc=cnr,dc=it Informazioni aggiuntive sull'utente 13

14 edupersonorgunitdn Riferimenti Il Distinguished Name della entry che rappresenta l'unità organizzativa di appartenenza alla quale la persona è associata (ad esempio Dipartimento) urn:mace:dir:attribute-def:edupersonorgunitdn urn:oid: [RFC4524] Sintassi LDAP Distinguished Name syntax Valori permessi n/d Esempi multiplo opzionale edupersonorgunitdn: ou=dipartimento di Fisica,o=unimore, dc=unimore,dc=it Informazioni aggiuntive sull'utente Autorizzazioni e accounting Questo gruppo di attributi può essere trasmesso dall organizzazione di appartenenza a determinati Fornitori di Servizi con i quali è stata valutata l utilità dei valori trasmessi ai fini della fornitura del servizio stesso. Tipicamente tali attributi vengono utilizzati per determinare il diritto di accesso al servizio. I primi tre attributi di questo gruppo contengono una parte in comune: la rappresentazione dell organizzazione di appartenenza: <organizzazione>, che deve essere un dominio DNS registrato dall organizzazione di appartenenza. Nel caso che un organizzazione abbia registrato più di un dominio DNS, per gli scopi della Federazione ne deve scegliere uno, comunicarlo alla Federazione e quindi usarlo nella valorizzazione degli attributi. edupersonscopedaffiliation Riferimenti Indica l'affiliazione dell'utente presso l'organizzazione di appartenenza, nella forma: <affiliazione>@<organizzazione> urn:mace:dir:attribute-def:edupersonscopedaffiliation urn:oid: Affiliazione secondo le convenzioni descritte nell'appendice B, in unione con l'organizzazione di appartenenza indicata nella forma <organizzazione> [EDUPER], [UK2] 3.2.2, [UK3] 7.1.2, Appendice A, Appendice B 14

15 Sintassi LDAP Directory String Valori permessi Note Esempi multiplo <affiliazione>: solo i valori permessi per edupersonaffiliation. Consultare le Appendici A e B per individuare la valorizzazione corretta. <organizzazione>: nome DNS Obbligatorio EduPersonScopedAffiliation permette la minima intrusione nella privacy dell utente, pur essendo sufficiente per decidere riguardo l autorizzazione all accesso nella maggior parte delle situazioni. L organizzazione di appartenenza dovrebbe rilasciare il valore meno intrusivo relativamente all utente coinvolto e al servizio acceduto; il fornitore di servizio deve progettare il proprio sistema di autorizzazione in modo da usare questo attributo ovunque possibile. [UK2] edupersonscopedaffiliation: staff@biblio.bo.cnr.it edupersonscopedaffiliation: faculty@unica.it Autorizzazione edupersontargetedid anonimo, persistente, non riassegnabile, di un utente che viene trasferito dall'organizzazione di appartenenza ad un Fornitore di Servizi (oppure ad un gruppo di Fornitori). L'organizzazione di appartenenza comunica ad ogni Fornitore di Servizi (oppure ad un gruppo di Fornitori) solo il valore appropriato e non rivela tale valore ad altri Fornitori di Servizi. urn:mace:dir:attribute-def:edupersontargetedid urn:oid: Ogni valore è un identificativo anonimo persistente associato all'utente per la fruizione di uno specifico servizio, ed è composto da tre parti, nella forma: <organizzazione>!<servizio>!<stringa opaca> Per <organizzazione> si intende l'identificativo dello IdP dell'utente. La <stringa opaca> deve essere univoca all'interno dell'organizzazione, e generata con un meccanismo di hashing di dati univoci relativi all'utente. Gli identificativi persistenti definiti in SAML 2.0 sono conformi a queste specifiche Riferimenti [EDUPER], [UK3] (par ) e [UK2] (par ), [SAML-C] (par ) Sintassi LDAP Directory String Valori permessi n/d Note Esempi multiplo Obbligatorio La stringa opaca non deve permettere al servizio di risalire direttamente all'identità dell'utente, ma consentire solo il suo riconoscimento nelle sessioni successive di accesso al servizio. Una volta utilizzato per un utente, il valore non può essere riutilizzato per un altro utente o servizio. solamente il suo riconoscimento univoco presso una istituzione. edupersontargetedid: biblio.bo.cnr.it!servizio_1!1304asf2rsfs edupersontargetedid: unica.it!servizio_n!alskdj92920alsk Autorizzazione, Accounting, Servizio personalizzato 15

16 edupersonprincipalname Riferimenti unico personale dell'utente urn:mace:dir:attribute-principalname urn:oid: Un identificativo che permette di riconoscere univocamente un utente in maniera coerente tra servizi diversi, nella forma: [EDUPER] Sintassi LDAP Directory String Valori permessi n/d Esempi Singolo Roccomandato edupersonprincipalname: edupersonprincipalname: Autorizzazione, Accounting edupersonentitlement Riferimenti URI (URN o URL) che indica il diritto di accesso ad una risorsa urn:mace:dir:attribute-def:edupersonentitlement urn:oid: I valori contenuti sono tipicamente delle URI che individuano una risorsa o una particolare proprietà dell'utente stesso. L'utente è autorizzato ad accedere ad una risorsa solo se edupersonentitlement contiene una particolare e predefinita URI. Sintassi LDAP DirectoryString Valori permessi n/d Note Multiplo raccomandato Sebbene la maggior parte delle decisioni sull'autorizzazione all'accesso vengano prese basandosi semplicemente su uno o più attributi, per alcuni servizi l'accesso sarà consentito solo se viene soddisfatto un insieme più complesso di condizioni difficilmente determinabili a priori dal Service Provider. Storicamente questo genere di applicazioni ha costretto il fornitore del servizio a mantenere la lista dei nomi utente per gli utenti autorizzati: un processo che risulta arduo da manutenere e anche rischioso per la privacy. A questo scopo è stato introdotto l'attributo edupersonentitlement: il fornitore del servizio definisce un valore univoco (formattato come URI) da assegnare a edupersonentitlement per marcare gli utenti che soddisfano determinate condizioni stabilite dal Fornitore. L'organizzazione di appartenenza è responsabile del controllo sui propri utenti, affinchè a coloro che soddisfano le condizioni venga assegnato il valore opportuno. La semplicità di manutenzione e la privacy in questo modo vengono migliorate. In generale edupersonentitlement non costituisce un dato personale, tuttavia ove ci siano soltanto pochi titolari di entitlement in una organizzazione po- 16

17 Esempi trebbe essere possibile la loro identificazione incrociando il dato con altre informazioni. Ad esempio, se edupersonentitlement viene utilizzato per consentire l'accesso a dati sensibili, tale valore può essere trattato solo dopo aver ottenuto il consenso scritto dell'utente. Pertanto, prima di assegnare un valore di edupersonentitlement ad un utente, l'organizzazione deve valutare se è necessario ottenere il consenso dall'utente. In ogni caso l'attributo edupersonentitlement deve venire rilasciato solamente a quei fornitori di servizi per i quali il valore è rilevante per il controllo dell'accesso. Con questo attributo il Fornitore di un Servizio, di fatto, delega l'organizzazione di Appartenenza a decidere su quali utenti autorizzare per l'accesso al servizio in quanto è proprio l'organizzazione dell'utente che valorizza questo attributo in accordo con i valori predefiniti con il fornitore del servizio. L'attributo potrebbe anche contenere dei valori che individuano una proprietà dell'utente (non definita con gli altri attributi) sulla base della quale ottenere l'autorizzazione per l'accesso al servizio. edupersonentitlement: edupersonentitlement: urn:mace:internet2:terena.nl:garr:service Autorizzazione Confidenzialità / Visibilità Può essere conveniente permettere all'utente di scegliere quali dei propri attributi l organizzazione di appartenenza deve mantenere privati e conseguentemente non deve trasmettere a certi SP piuttosto che ad altri. L'utente deve essere reso consapevole che tali scelte possono comportare la negazione del servizio da parte dell'sp. Sebbene mediante i file di configurazione di Shibboleth sia possibile decidere se o non rilasciare anche determinati valori per determinati attributi, per consentire all'utente di decidere autonomamente quali attributi rilasciare è conveniente considerare l'utilizzo di uapprove ( support/tools/uapprove.h) 17

18 Bibliografia Federazione Inglese [UK1] [UK2] Rules of membership for the federation, -of-membership.pdf Recommendations for use of personal data, mmendations-for-use-of-personal-data.pdf [UK3] Technical Recommendations for participants, nical-recommendations-for-participants.pdf [UK4] [UK5] Federation technical specifications, ation-technical-specifications.pdf Federation operator procedures, ation-operator-procedures.pdf Federazione Svizzera [SW1] [SW2] [SW3] [SW4] [SW5] AAI Service Agreement, AAI Service Agreement exhibits, pdf AAI Federation Partner Agreement, AAI Federation Partner Agreement Policy, Authorization Attribute Specification, 18

19 [SW6] swissedu.schema, Federazione Spagnola [ES1] irisuserprivateattribute, e/ Federazione Norvegese [NO1] [NO2] noredu* Object Class Specification, Feide edupersonaffiliation, RFC [RFC4519] [RFC2798] [RFC4524] [RFC3986] [RFC1737] [RFC2141] [RFC3305] Lightweight Directory Access Protocol (LDAP): Schema for User Applications, Definition of the inetorgperson LDAP Object Class, COSINE LDAP/X.500 Schema, Uniform Resource Identifier (URI): Generic Syntax, Functional Requirements for Uniform Resource Names, URN Syntax, Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations, 19

20 Altri Schemi LDAP [EDUPER] [SHAC] EduPerson Object Class Specification (200712), SCHAC - SCHema for ACademia - Attribute Definition For Individual Data, SAML [SAML-A] [SAML-C] MACE-Dir SAML Attribute Profiles, Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, Protezione dei dati personali e sensibili [DL19603] [EU1] [EU2] Decreto Legislativo 30/6/2003 n.196: Codice in materia di protezione dei dati personali, Protezione dei dati nell Unione Europea, Direttive Europee, 20

21 Appendice A Risoluzione e filtraggio degli attributi Verrà inserita nella prossima revisione del documento 21

22 Appendice B Capire l'affiliazione L'Affiliazione definisce la relazione che esiste tra l'utente e la propria organizzazione di appartenenza. Per descrivere l'affiliazione all'interno delle comunità scientifiche Internet2 propone lo schema EduPerson [EDUPER] con gli attributi EduPersonAffiliation e EduPersonPrimaryAffiliation. A questi attributi è associabile soltanto un'insieme predefinito di valori elencati nel documento di riferimento. Tali valori sono: faculty, student, staff, alum, member, affiliate, employee, library-walk-in. La lista di valori ammissibili è certamente incompleta. Si ritiene tuttavia che prima di aggiungere nuovi valori sia necessaria una discussione e l'approvazione da parte del gruppo di riferimento di Internet2. Qualora si concordasse per l'inserimento di ulteriori valori, questi verranno aggiunti alle successive versioni del documento di riferimento. Deliberatamente non è stato incluso il valore other oppure misc perché sarebbe semanticamente equivalente a nessuno dei precedenti. Volendo indicare tale valore per una specifica persona, l'attributo dovrà essere non valorizzato. I valori elencati individuano delle classi di persone; alcune classi sono specializzazioni di altre. In questa versione del documento, per gli scopi della Federazione, vengono definiti soltanto i valori student, staff, alum, member, affiliate. L'uso degli altri valori per gli scopi della Federazione è sconsigliato fino a che non ne venga definito un significato unanimemente condiviso. Il valore staff indica tutto il personale (docenti, personale amministrativo, bibliotecario e tecnico di supporto) in servizio presso l'organizzazione di appartenenza, con qualunque tipo di contratto, anche a tempo determinato, oppure rientrante nei contratti cosiddetti atipici (co.co.co, prestazioni professionali, interinali, ecc...). Con student si indicano gli studenti regolarmente iscritti ad uno dei corsi dell'organizzazione di appartenenza. student e staff sono due specializzazioni distinte di member. member contiene tutte le persone che hanno un rapporto istituzionale con l'organizzazione di appartenenza e ai quali viene dato un insieme base di privilegi. 22

23 Comprende student, staff, e tutti coloro che, pur non rientrando nelle classi precedenti, hanno rapporti istituzionali con la comunità scientifica. Affiliate si applica alle persone con le quali l'organizzazione di appartenenza ha una qualsiasi forma di rapporto ed alle quali è necessario attribuire una identità di utente, ma alle quali non vengono estesi i privilegi derivanti dall'essere membri dell'organizzazione stessa. Potrebbero rientrare in questa categoria i fornitori di servizi o materiali delle organizzazioni, ricercatori di altre organizzazioni che collaborano con un gruppo interno, persone per le quali è necessaria l'identificazione per servizi molto particolari riservati ad esterni all'università stessa. Normalmente gli affiliate non sono member, se non in casi eccezionali: ad esempio uno studente che sia anche dipendente di una ditta che fornisce servizi ad un'università. alum comprende gli ex studenti dell'organizzazione di appartenenza,che hanno completato almeno il primo livello di studi. Può capitare che un alum sia anche staff dell'organizzazione, oppure affiliate. È utile rappresentare le classi descritte nella seguente modalità visuale in cui vengono evidenziate le specializzazioni: L'attributo EduPersonAffiliation può assumere valori multipli, pertanto, se una persona appartiene ad una classe specializzata, per il principio dell'ereditarietà assume nell'attributo EduPersonAffiliation anche i valori delle classi superiori. Ad esempio un docente avrà sempre: EduPersonAffiliation: staff EduPersonAffiliation: member Uno studente avrà sempre: EduPersonAffiliation: student EduPersonAffiliation: member 23

24 È possibile il caso di uno studente che abbia anche una borsa di studio oppure un contratto con la stessa organizzazione per svolgere un compito istituzionale: pertanto egli avrà: EduPersonAffiliation: student EduPersonAffiliation: staff EduPersonAffiliation: member Se un dipendente amministrativo si è anche laureato nella stessa università, avrà: EduPersonAffiliation: staff EduPersonAffiliation: member EduPersonAffiliation: alum Solo in casi veramente eccezionali un affiliate avrà anche un altro valore per EduPersonAffiliation. Solo una minoranza tra tutti gli alum avranno anche altri valori in EduPersonAffiliation. In riferimento all'attributo EduPersonPrimaryAffiliation, anche se questo attributo non viene ritenuto al momento importante per la federazione, esso può assumere gli stessi valori con lo stesso significato attribuito ad EduPersonAffiliation. Ad ogni persona viene assegnato un unico valore per EduPersonPrimaryAffiliation, scelto tra quelli attribuiti a EduPersonAffiliation, tale che descriva al meglio l'attività della persona. Per gli scopi della federazione anziché usare EduPersonAffiliation si preferisce usare EduPersonScopedAffiliation, perché nello stesso attributo è specificata l'organizzazione di appartenenza, oltre al tipo di affiliazione. In questo modo si ottengono informazioni anche sull'organizzazione di appartenenza dell'utente ed il tipo di rapporto che questi ha con la corrispondente organizzazione. Per definire l'attributo EduPersonScopedAffiliation occorre considerare per ciascun utente i valori di EduPersonAffiliation ed aggiungere in coda ai valori il e l'indicazione dell'organizzazione nella forma di security domain, che per convenzione è il dominio registrato (secondo la convenzione per il Domain Name Service) per l'organizzazione di appartenenza. Ad esempio, un tecnico dell'università di Modena e Reggio Emilia avrà: EduPersonScopedAffiliation: staff@unimore.it EduPersonScopedAffiliation: member@unimore.it Corrispondenza tra le categorie note e le possibili affiliazioni La seguente tabella di corrispondenze consente ai membri della Federazione di 24

25 assegnare ai propri utenti valori semanticamente uniformi per l'attributo edu- PersonScopedAffiliation. La prima tabella si riferisce a ruoli censiti in ambito universitario e negli istituti di ricerca. N.B. Qualora per alcuni contesti esistano ruoli non previsti nella tabella seguente occorrerà darne comunicazione al Comitato Tecnico Scientifico, che provvederà alla modifica delle stesse, evitando di assegnare a tali utenti ruoli inappropriati. assistenti universitari Ruolo edupersonaffiliation collaboratore coordinato continuativo collaboratori ed esperti linguistici convenzionato (cliente delle convenzioni) cultore della materia dipendente altra università dipendente altro ente di ricerca dipendente azienda ospedaliera/policlinico dipendente di altra azienda sanitaria dirigente dirigente a contratto dirigente di ricerca dirigente tecnologo docente a contratto dottorando dottorando di altra università (consorziata) fornitore (dipendente o titolare delle ditte fornitrici) interinale laureato frequentatore/collaboratore di ricerca (a titolo gratuito) lavoratore occasionale (contratto personale senza partita iva) libero professionista (contratto personale con partita iva) personale tecnico-amministrativo a tempo determinato ospite personale tecnico-amministrativo primo ricercatore primo tecnologo professore associato professore emerito affiliate member member member member, student member affiliate member affiliate member 25

26 professore fuori ruolo professore ordinario ricercatore specializzando studente studente erasmus in ingresso studente laurea specialistica studente master studente siss supervisore siss tecnologo titolare di assegno di ricerca titolare di borsa di studio tutor volontario servizio civile nazionale Ruolo edupersonaffiliation member, student student, member student student, member student, member student, member member member N.B. L'affiliazione alum può essere aggiunta a tutti i ruoli, ove risultasse applicabile. Configurazione di Shibboleth Una volta compreso il significato dell'affiliazione e avendo chiaro in quale delle precedenti categorie rientrano i propri utenti occorre configurare Shibboleth in maniera che restituisca tali valori. Come risulta chiaro da quanto descritto in precedenza, l'attributo utilizzato è edupersonscopedaffiliation. La configurazione di Shibboleth 2.x può essere effettuata in due modi diversi in funzione del fatto che i valori da restituire siano o no già presenti nel backend (LDAP o DBMS). Per la configurazione di edupersonscopedaffiliation, come risulta evidente dallo stesso nome, occorre utilizzare un attributo di tipo scoped, indicando come scope il proprio dominio. N.B. È importante fare attenzione che lo scope utilizzato coincida con quello dichiarato nei metadati Nel caso in cui i valori di affiliazione siano già presenti nel backend è sufficiente configurare sourceattributeid con il nome dell'attributo contente tali valori, avendo cura di indicare anche il riferimento alla sorgente di tali attributi. 26

27 La configurazione potrebbe quindi essere: <resolver:attributedefinition id="edupersonscopedaffiliation" xsi:type="scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="ifc.cnr.it" sourceattributeid="affiliation"> <resolver:dependency ref="myldap" /> <resolver:attributeencoder xsi:type="saml1scopedstring" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:edupersonscopedaffiliation" /> <resolver:attributeencoder xsi:type="saml2scopedstring" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid: " friendlyname="edupersonscopedaffiliation" /> </resolver:attributedefinition> Nella maggior parte dei casi avere l'attributo relativo all'affiliazione già presente in maniera esplicita nel proprio backend può risultare un inutile spreco di spazio oltre che di tempo (necessario per valorizzare l'attributo ad ogni nuovo inserimento di un utente). In genere la stessa informazione è già presente in maniera più dettagliata attraverso l'attributo che descrive la posizione contrattuale dell'utente nei confronti della propria organizzazione. In tal caso è possibile determinare l'affiliazione in base ai valori di questo attributo. Per fare ciò, nell'attributeresolver.xml, è necessario definire un mapped attribute, che mappi i valori nel backend con i valori previsti per l'affiliazione come indicato nella tabella vista nel paragrafo precedente. La configurazione potrebbe essere: <resolver:attributedefinition id="edupersonaffiliation" xsi:type="mapped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" dependencyonly="true" sourceattributeid="employeetype"> <resolver:dependency ref="myldap" /> <resolver:attributeencoder xsi:type="saml1string" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:edupersonaffiliation" /> <resolver:attributeencoder xsi:type="saml2string" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid: " friendlyname="edupersonaffiliation" /> <DefaultValue>affiliate</DefaultValue> <!-- per ora non sono stati trovati casi che rientrano in questa categoria <ValueMap> <ReturnValue>alum</ReturnValue> </ValueMap> --> <!-- da completare con i ruoli all'interno del proprio ente --> <ValueMap> <ReturnValue>affiliate</ReturnValue> <SourceValue>convenzionato</SourceValue> 27

28 <SourceValue>fornitore</SourceValue> <SourceValue>ospite</SourceValue> </ValueMap> <ValueMap> <ReturnValue>member</ReturnValue> <SourceValue>dirigente tecnologo</sourcevalue> <SourceValue>dirigente di ricerca</sourcevalue> <SourceValue>primo tecnologo</sourcevalue> <SourceValue>primo ricercatore</sourcevalue> <SourceValue>tecnologo</SourceValue> <SourceValue>ricercatore</SourceValue> <SourceValue>personale tecnico-amministrativo</sourcevalue> <SourceValue>specializzando</SourceValue> </ValueMap> <ValueMap> <ReturnValue>staff</ReturnValue> <SourceValue>dirigente tecnologo</sourcevalue> <SourceValue>dirigente di ricerca</sourcevalue> <SourceValue>primo tecnologo</sourcevalue> <SourceValue>primo ricercatore</sourcevalue> <SourceValue>tecnologo</SourceValue> <SourceValue>ricercatore</SourceValue> <SourceValue>personale tecnico-amministrativo</sourcevalue> <SourceValue>specializzando</SourceValue> </ValueMap> <ValueMap> <ReturnValue>student</ReturnValue> <SourceValue>studente</SourceValue> <SourceValue>studente laurea specialistica</sourcevalue> <SourceValue>specializzando</SourceValue> </ValueMap> </resolver:attributedefinition> <resolver:attributedefinition id="edupersonscopedaffiliation" xsi:type="scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="ifc.cnr.it"> <resolver:dependency ref="edupersonaffiliation" /> <resolver:attributeencoder xsi:type="saml1scopedstring" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:edupersonscopedaffiliation" /> <resolver:attributeencoder xsi:type="saml2scopedstring" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid: " friendlyname="edupersonscopedaffiliation" /> </resolver:attributedefinition> Nell'esempio precedente è stato definito l'attributo edupersonaffiliation utilizzato poi da edupersonscopedaffiliation. L'attributo non verrà comunicato all'esterno (dependencyonly="true"). L'attributo, nel server LDAP, che contiene i valori relativi alla posizione contrattuale è employeetype. In base alla precedente configurazione, nel caso in cui una determinata posizione non fosse prevista, l'utente verrebbe considerato come affiliate (DefaultValue). 28

29 Appendice C Note su edupersontargetedid edupersontargeteid (in breve eptid) è un attributo con il quale viene implementato il concetto di persistent identifier di SAML 2.0. Un Fornitore di Servizi usa questo attributo per realizzare, tramite pseudonimo, il meccanismo delle sessioni garantendo il riconoscimento dell'utente che accede in tempi diversi, offrendogli così una personalizzazione del servizio stesso nel rispetto della propria privacy. L'attributo, definito nella prima versione di eduperson del 2003 e ridefinito poi nella versione successiva del 2006 [eduperson] per essere conforme a quanto indicato in SAML 2.0, permette all'organizzazione di Appartenenza dell'utente di creare una relazione uno-a-molti, anonima e permanente fra lo stesso utente ed i Fornitori di Servizi. Formato dei valori Ai fini della Federazione IDEM la sintassi dell'attributo eptid è quella definita nell'ultima versione di eduperson [eduperson] ed aderente alla sintassi consigliata in SAML 2.0 (SAML2 PersistentID). I valori dell'attributo saranno formati da un identificativo del SP, un identificativo dell'idp ed una stringa opaca che identifica in maniera anonima ma univoca l'utente. Per Shibboleth 1.3 è necessario riferirsi all'attributo tramite l'oid per ottenere la sintassi corretta. Ad una richiesta dell'attributo urn:oid: quindi, verrà restituito un valore del tipo: namequalifier!spnamequalifier!stringa_opaca dove la stringa opaca è ricavata a partire dall'hashing di 4 valori noti all'idp: (namequalifier, SPNameQualifier, sourcename, salt), dove NameQualifier è l'identificativo dell'idp o security domain, SPNameQualifier è il nome identificativo del servizio offerto dal SP (o da un gruppo di SP che devono condividere lo stesso valore di EduPersonTargetedId), sourcename è un valore identificativo per l'utente (potrebbe essere l'uid come nell'esempio o l'uidnumber oppure ancora un numero generato in maniera casuale e poi associato all'utente) purché univoco all'interno dell'organizzazione, salt è una stringa di lunghezza arbitraria uguale per tutti gli utenti. 29

30 Una richiesta dello stesso attributo tramite il nome produrrà un valore non conforme alla definizione di eptid data nel documento di eduperson del 2006 ma alla versione precedente del Configurazione dell'attributo È importante notare che ai fini del corretto funzionamento della Federazione ciò che è necessario regolamentare è il formato dell'attributo eptid. La scelta su come questo valore debba essere generato e/o trattato resta a carico dell'idp. Al solo scopo di agevolare la decisione si possono fare alcune considerazioni. La gestione dell'attributo eptid comporta qualche difficoltà a causa della sua dipendenza da altri attributi. La generazione dei valori, conseguente ad una richiesta, può essere effettuata con due modalità: 1. Algoritmica. In questo modo i valori vengono generati ad ogni richiesta partendo da valori dipendenti dall'utente dall'idp e dal SP, come esemplificato in precedenza. In questo modo si evita la necessità, da parte dell'idp, di memorizzare i valori dell'attributo. Questo metodo comporta lo svantaggio di ottenere valori diversi al variare di uno degli attributi usati per la generarazione dei valori stessi, con la conseguenza di perdere eventuali personalizzazioni e/o la possibilità di modificare dati precedentemente memorizzati presso i Fornitori di Servizi. Di contro ha il vantaggio di essere più semplice da gestire. In Shibboleth 2 questo metodo è sconsigliato in favore del metodo per memorizzazione. 2. Per memorizzazione. L'alternativa al metodo precedente è quella di memorizzare tutti i valori generati per eptid. Questo metodo comporta lo svantaggio di dover memorizzare un elevato numero di valori oltre alla necessità, anche utilizzando LDAP come backend, di disporre di un database, anche se per una sola tabella, per salvare i valori esistenti. Inoltre, ad ogni richiesta dell'attributo occorre verificare i valori esistenti restituendo solo quello relativo all'sp richiedente o generarlo, nel caso non esista, (al primo utilizzo del servizio da parte dell'utente il valore viene generato come per la gestione algoritmica). Al contrario ha il vantaggio di poter consentire la revoca dell'attributo e la rigenerazione con un valore differente (utilizzando un diverso valore per il salt) senza la necessità di rigenerare tutti gli altri valori e può essere utilizzato come identificativo SAML 1 o 2. Infatti essendo il valore generato tramite un algoritmo di hashing, non invertibile, senza memorizzazione non si potrebbe risalire all'utente associato. 3. Da quanto detto risulta evidente che Shibboleth 2.x può essere configurato per generare i valori in entrambe le modalità, la scelta sarà quindi del tutto personale (fermo restando, come detto, che Internet2 considera "deprecata" la modalità algoritmica). La soluzione algoritmica risulta quindi la 30

31 più semplice da un punto di vista implementativo, motivo per cui verrà riportata come esempio di configurazione (per maggiori dettagli sulla configurazione per memorizzazione e sui campi necessari alla tabella si faccia riferimento alla documentazione di Shibboleth 2). Nell'attribute-resolver.xml di Shibboleth 2.x viene prima definito l'attributo edu- PersonTargetedID come computedid (attributo generato dinamicamente) : <resolver:attributedefinition id="edupersontargetedid" xsi:type="saml2nameid" xmlns="urn:mace:shibboleth:2.0:resolver:ad" nameidformat="urn:oasis:names:tc:saml:2.0:nameid-format:persistent" sourceattributeid="computedid"> <resolver:dependency ref="computedid" /> <resolver:attributeencoder xsi:type="saml1xmlobject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid: " /> <resolver:attributeencoder xsi:type="saml2xmlobject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid: " friendlyname="edupersontargetedid" /> </resolver:attributedefinition> Successivamente devono essere configurati i parametri opportuni per il ComputedId: <resolver:dataconnector xsi:type="computedid" xmlns="urn:mace:shibboleth:2.0:resolver:dc" id="computedid" generatedattributeid="computedid" sourceattributeid="uid" salt="<stringa casuale>"> <resolver:dependency ref="myldap" /> </resolver:dataconnector> Nell'esempio il sourceattributeid, l'attributo di partenza da cui viene calcolato l'hash, è l'uid. La stringa casuale deve essere lunga almeno 16 caratteri ma è consigliabile che siano 48. Anche in questo caso il valore che il Service Provider otterrà sarà una stringa formata come descritto nel precedente paragrafo. A tal proposito si può notare che la configurazione di default dell'attribute-map.xml del Service Provider, per la ricezione di eptid, prevede tre modalità: <!-- First, the deprecated version: --> <Attribute name="urn:mace:dir:attribute-def:edupersontargetedid" id="targeted-id"> <AttributeDecoder xsi:type="scopedattributedecoder"/> </Attribute> <!-- Second, the new version (note the OID-style name): --> 31