Buongiorno, stiamo adeguando un Service Provider per supportare OIDC oltre a SAML2. Per validare la soluzione abbiamo necessità di eseguire dei test. Le informazioni che devono essere scambiate sono:
i metadati del nostro Relying Party di test che dobbiamo inviare ad AgID
i metadati di un provider di test che AgID invia a noi
confermate? Dobbiamo forse includere nei nostri metadati una busta “trust_marks” contenente l’elemento “trust_mark” tornatoci a seguito della registrazione del nostro Service Provider di test nella federazione?
Avremmo quindi bisogno dei riferimenti da contattare per eseguire l’onboarding ed i successivi test.
AgID non ha ancora avviato l’onboarding per SP basati su SPID OIDC, né rilasciato ufficialmente strumenti di test.
E’ in fase di sviluppo questo progetto, ma è ancora in fase alpha.
Può essere utilizzato per alcune verifiche preliminari, ma non per un vero e proprio rilascio.
Avevamo già ispezionato il codice di esempio “relying-party-spring-boot” e verificata con successo l’autenticazione OIDC con l’applicazione “spid_cie_oidc.provider” dopo aver federato il servizio utilizzando l’applicazione “spid_cie_oidc.onboarding” (entrambe docker-izzate).
Rimaniamo in attesa di indicazioni per l’onboarding sulla federazione di test.
Buongiorno, mi aggrego alla discussione per chiedere se ci sono novità sull’ambiente di test per OIDC. Il progretto spid-cie-oidc-django sembra sia stato rilasciato, ma non trovo informazioni su come effettuare dei test analogamente a quanto avviene per SAML con spid-saml-check e l’ambiente demo.
C’è qualche novità in merito? Grazie
Buongiorno @Fabio_Grasso ,
gli ambienti di test SPID OIDC per Relying Party sono in corso di sviluppo.
Contiamo a breve di poterli rilasciare pubblicamente.
Buongiono, sono il responsabile tecnico di un progetto per lo sviluppo di diversi servizi per le PA e,
a seguito del rilascio delle nuove linee guida, abbiamo intrapreso direttamente la strada OIDC per l’autenticazione SPID/CIE.
Tuttavia, dopo aver effettuato tutti i test disponibili tramite SDK django ci chiedevamo se tale sistema possa entare in produzione a “stretto giro” o dobbiamo ripiegare, nell’attesa, sull’integrazione SAML2.
Buonasera @Eduardo1977 ,
una prima versione dell’ambiente di test per i Relying Party è disponibile all’indirizzo:
L’ambiente consente la validazione del metadata, fornito all’endpoint .well-known/openid-configuration e la validazione del flusso di AuthCode Flow, inviando una Request all’OP del Validator dal proprio Relying Party.
Ulteriori test verranno aggiunti progressivamente.
A questo punto però vorrei chiedere:
-Esiste un OP di test per poter testare l’autenticazione SPID OIDC? (In pratica qualcosa di simile a quanto esiste per lo SPID SAML: https://demo.spid.gov.it)
-Nella configurazione del pulsante per l’accesso SPID, che indirizzo devo riportare come “Trusted anchor”?
@Alberto_Pagani hai trovato qualche soluzioni a riguardo? perchè sono nella tua stessa situazione e non riesco a capire come effettuare dei test analoghi a quelli effettuati con https://demo.spid.gov.it
che consente di verificare il flusso di autenticazione OIDC del Relying Party.
La modalità “demo” sul validatore RP, analoga alla modalità demo di spid-saml-check è in corso di sviluppo.
Vi aggiornerò quando verrà rilasciata pubblicamente.
Buongiorno @damikael ,
ho dato un’occhiata alle linee guida OIDC e vi chiedo alcuni chiarimenti riguardo la parte RP/SA. Se volessi adottare lo scenario in cui ho un mio Soggetto Aggregatore Full che vuole autenticare l’utente esponendo un’interfaccia con vari OpenID Provider che l’utente stesso può scegliere, come dovrei gestire la chiamata che un Relying Party esterno effettua a tale SA e che tale SA riscrive quando si presenta all’OP scelto dall’utente? Ho letto anche che un SA Full deve esporre il metadata OIDC Federation dei propri aggregati ed anche un indirizzo di callback. Come riesce ciascun RP ad ottenere i claim chiesti all’Authorization Endpoint dell’SA quando riceve la risposta dell’SA alla richiesta di authorization? Grazie.
Buongiorno @Luca_Montano ,
la comunicazione tra SA e suoi aggregati è di responsabilità del SA e le specifiche di implementazione per la trasmissione dei claim verso il RP aggregato, possono essere definite dallo stesso SA.
