Latest revision as of 14:41, 3 April 2014

Single sign-on

L'esigenza è quella di realizzare un sistema per il controllo degli accessi in grado di consentire, a tutti gli utenti afferenti a RITMARE, l'utilizzo di un unico profilo per accedere a tutti i servizi web che compongono l'infrastruttura interoperabile.

Use cases

Elenco di alcuni use cases che andrebbero supportati, da verificare e complementare:

UC1 - Accesso semplice da istanza di Starter Kit allo stesso nodo:
- L'amministratore locale del nodo ha creato a tempo debito gli account per gli utenti che dovranno accedere al nodo in lettura e/o scrittura. Due possibilità:
  - l'utente NON è un utente Ritmare e potrà quindi accedere al solo nodo locale (decidere se solo in lettura o se dare anche l'opzione di creare un utente non-Ritmare con diritti di modifica;
  - l'utente è un utente Ritmare perchè l'email associata al suo account è tra quelle dei partecipanti al progetto. Viene creao un certificato per l'utente; decidere come questo possa essere recuperato dall'utente.
- L'utente accede al nodo utilizzando l'account che è stato creato per lui.

UC2 - Accesso dal portale centrale ad una risorsa messa a disposizione da un nodo presso il quale l'utente non ha un account.

...

WebID

https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html (pubblicata il 2 Aprile 2014)

OpenID

OpenID sembra essere tra le soluzioni più interessanti utilizzabili per implementare un sistema di autenticazioni SSO. In particolare, sembra adattarsi bene all'approccio linked data/FOAF adottato per la rappresentazione del profilo dei Ricercatori/Utenti afferenti.

Intro Wikipedia: http://en.wikipedia.org/wiki/OpenID
Esempio di Service Provider implementato dall'infrastruttura Creative Commons: https://creativecommons.net/h/openid/
Howto per l'integrazione di WebID e OpenID attraverso Virtuoso per ottenere un SSO senza username e password

Infrastruttura RITMARE é OpenID

OpenID provider OD, dove ogni utente può gestire il proprio profilo e l'amministratore centrale può associare il profilo a differenti ruoli/permessi.
Il nodo centrale e i nodi GeoSK possono autenticare l'utente utilizzando l'OpenID provider.
Gli amministratori dei singoli nodi periferici possono continuare a gestire gli utenti locali. Questo per consentire l'accesso a singole risorse e/o funzionalità anche a utenti esterni a RITMARE.

Possibili implementazioni

Client

Django Social Auth: tra quelle disponibili per Django è quella più matura con una comunità molto attiva
- Codice https://github.com/omab/django-social-auth
- Documentazione http://django-social-auth.readthedocs.org/
Il progetto è stato riversato nel nuovo progetto Python Social Auth https://github.com/omab/python-social-auth

Server (OpenID provider)

OpenAM http://openam.forgerock.org/ : strumento completo ma forse un po' troppo complesso perché, oltre allo standard OpenAM, implementa numerosi altri sistemi di autenticazione federata.
TODO [ricerca da completare]

@@ Line 4: / Line 4: @@
 == Use cases ==
 Elenco di alcuni use cases che andrebbero supportati, da verificare e complementare:
 * UC1 - Accesso semplice da istanza di Starter Kit allo stesso nodo:
 ** L'amministratore locale del nodo ha creato a tempo debito gli account per gli utenti che dovranno accedere al nodo in lettura e/o scrittura. Due possibilità:
 *** l'utente NON è un utente Ritmare e potrà quindi accedere al solo nodo locale (decidere se solo in lettura o se dare anche l'opzione di creare un utente non-Ritmare con diritti di modifica;
 *** l'utente è un utente Ritmare perchè l'email associata al suo account è tra quelle dei partecipanti al progetto. Viene creao un certificato per l'utente; decidere come questo possa essere recuperato dall'utente.
+** L'utente accede al nodo utilizzando l'account che è stato creato per lui.
+* UC2 - Accesso dal portale centrale ad una risorsa messa a disposizione da un nodo presso il quale l'utente non ha un account.
+...
 == WebID ==

Difference between revisions of "SSO"