Configurazione Identity Provider

[alranel]

Dobbiamo definire quali sono i parametri presenti nella configurazione degli Identity Provider, utili al rendering e al funzionamento dello Smart Button.

Sicuramente servono i seguenti parametri:

• entityId: è una URI, ad esempio https://identity.infocert.it o https://posteid.poste.it
• logo: URL al logo ospitato nella CDN di SPID (valutare se ripetere questo elemento per i vari formati dimensionali previsti dalle linee guida UX)
• entityName: nome pubblico dell'Identity Provider (non è la ragione sociale dell'azienda ma è il nome del servizio da visualizzare)
• protocols: array che può contenere i valori SAML e OIDC (uno solo o entrambi); serve ad indicare se questo Identity Provider supporta solo l'uno o entrambi; in questo modo il Service Provider può indicare al bottone quale protocollo richiede e ingrigire/nascondere gli IdP che non lo supportano (siamo in attesa di decidere quale dev'essere esattamente il comportamento)

C'è da considerare un aspetto. Quando un utente clicca su un IdP, il bottone chiama un endpoint del SP a cui passa l'IdP scelto dall'utente, così che questo endpoint possa preparare la AuthnRequest SAML ed avviare il processo di autenticazione reindirizzando l'utente sull'IdP. Ad esempio, cliccando su Aruba andrò a questa pagina: /spid/login?idp=aruba che a sua volta mi reindirizzerà su Aruba.
Il parametro da passare però dipende da come è implementato ogni singolo SP. Ad esempio potrei avere i seguenti casi:

/spid/login?idp=aruba
/spid/login/aruba
/spid/login?entityId=https%3A%2F%2Floginspid.aruba.it
/spid/login?idp=3

Nei primi due casi si usa una stringa breve associata a ciascun IdP, ma questa stringa non è definita ufficialmente nel registro SPID. Nel quarto caso si usa un indice posizionale dell'IdP, che potrebbe essere quello con cui compaiono gli IdP nel registro SPID (ma dobbiamo scrivere da qualche parte che l'ordine degli IdP nel registro è ufficiale e cristallizzato - e comunque questo creerebbe problemi nel caso in cui un IdP dovesse cessare).

In tutti i componenti open source SPID in Developers Italia io tenderei ad utilizzare sempre l'entityID come chiave primaria, anche se è lungo è comunque il più corretto. Chi non usa l'entityID può semplicemente farsi il suo mapping tra entityID e il suo alias locale, soprattutto se adottiamo il callback descritto in #3

cc @umbros

[simevo]

se mi metto nell'ottica di un consumer di questo componente (ad esempio spid-php), in fase di test di spid-php sarebbe utile configurare il bottone SPID in modo che mostri come unico idp l'idp di test (es. testenv2)

questo file contiene alcuni dei campi che servono:

{
  "provider": "poste",
  "title": "Poste",
  "logo": "spid-idp-posteid.svg",
  "isActive": true
}

ma non il primo e l'ultimo:

• entityID: manca, si potrebbe mettere al posto del campo provider
• logo: logo svg che quindi è totalmente scalabile
• entityName: title (ma non sembra essere obbligatorio)
• protocols: manca

in compenso c'è della roba in più:

• il campo isActive (può servire)
• tre idp dummy: newidp1, newidp2 e newidp3

però attualmente in agid-spid-enter-config.js non usa il file src/data/spidProviders.json e se lo prende dal providersEndpoint che è impostato a https://rawgit.com/srescio/spid-smart-button/issue-2/separate-html-js/src/data/spidProviders.json (?)

vedo due due possibilità per consentire anche ai consumers di modificare la configurazione degli idp:

1. spostare spidProviders.json in dist e settare providersEndpoint = /js/spidProviders.json
2. oppure esporre providersEndpoint in modo che il consumer lo possa cambiare a suo piacimento

[ZorbaDimatteo]

Dalla lista dei providers https://registry.spid.gov.it/api/identity-providers vedo che c'è una lista di providers con campi:

• entityID
• entityName
  dove mancano però logo e protocols.

Io sarei (per il momento) per inserire una lista fissa dei providers attualmente disponibili e quindi creare un json come nella tua proposta numero 1, che può essere quindi modificabile anche dai consumers.
Lo schema del json diventerebbe quindi qualcosa del genere:

{
            "entityName": "Aruba",
            "logo": "spid-idp-aruba.svg",
            "entityID" : "https://www.pec.it/",
            "isActive": true,
            "protocols": ["SAML", "OICD"]
}

Dove possiamo reperire le informazioni sui protocols?

[alranel]

Sì, includiamo questa lista staticamente nel repository, senza andare ad interrogare il Registro.
isActive (facciamo active) mi pare una buona idea. Mostriamo in grigio quelli non attivi.

La lista non possono modificarla perché sarà hard-coded nel codice pacchettizzato e minificato del bottone. Aggiungiamo un elemento extraProviders contenente un array di oggetti con le configurazioni da aggiungere a quelle standard.
Presto scriverò ulteriori dettagli.

[alranel]

Aggiornamento: non servono più dimensioni per i loghi degli IdP, la dimensione necessaria è unica.

[alranel]

Per rispondere a @ZorbaDimatteo: tutti gli IdP esistenti supportano SAML (e solo quello) per adesso.

[francescoscialacqua]

Scusate l'intromissione in questo post ma capisco che potete fornirmi informazioni a me indispensabili. Sto cercando di configurare lo SPID SAML Check Ho tutto pronto compreso il metadata.xml ma non capisco dove metterlo sul mio SP e come inserire nella lista degli IdP SPID SAML Check