Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sviluppo plugin per autenticazione SPID su Django #1

Closed
alranel opened this issue Sep 21, 2017 · 0 comments
Closed

Sviluppo plugin per autenticazione SPID su Django #1

alranel opened this issue Sep 21, 2017 · 0 comments

Comments

@alranel
Copy link
Member

alranel commented Sep 21, 2017

Ci sono due strade per implementare un plugin per Django:

  1. usare un middleware come Shibboleth
  2. implementare tutto direttamente nel plugin

1. Usando Shibboleth

Pro: plugin più snello, più facile da implementare e testare, più manutenibile.
Contro: aggiunge il requisito di Shibboleth, sia in sviluppo sia in deployment.

Shibboleth è un middleware, ovvero un plugin per il web server (Apache/nginx) abbinato ad un demone che si occupa di gestire il protocollo SAML nelle interazioni con l'Identity Provider e le Attribute Authorities. Esiste già un playbook Ansible che installa un'istanza di Shibboleth+nginx preconfigurata per SPID.

Un plugin per Django dovrebbe essenzialmente:

  • verificare se l'utente è già autenticato o no (come un qualsiasi plugin di autenticazione)
  • esporre il bottone di login che consente all'utente di scegliere l'Identity Provider a cui inviare la richiesta; per indicazioni vedere questo commento
  • popolare un oggetto user di Django con gli attributi restituiti dall'Identity Provider

Link utili:

2. Implementando tutto nel plugin

Per evitare l'installazione di Shibboleth è possibile realizzare un plugin autonomo che gestisce tutto. Anche in questo caso bisogna esporre il bottone di login come sopra descritto, ma poi bisogna:

  • usare una libreria SAML per preparare la AuthnRequest da includere nel redirect HTTP con cui si manda l'utente all'Identity Provider scelto
  • esporre un endpoint HTTP (l'Assertion Consumer Service) a cui l'Identity Provider invia le proprie asserzioni (per esempio: l'esito del login)
  • mantenere in questo repository i metadati XML degli Identity Provider accreditati SPID

Come riferimento, queste sono le principali implementazioni di SAML per Django esistenti:

Queste librerie assumono un'architettura in cui è presente un solo Identity Provider, hard-coded nella configurazione, per cui manca lo step di selezione da parte dell'utente (che invece a noi serve: dobbiamo mostrare il bottone di login).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants