search

italia / spid-shibboleth-proxy-docker

SPID authentication proxy based on Shibboleth service provider
European Union Public License 1.2
22 stars 11 forks source link

Validazione response #26

Open 154ngroves opened 5 years ago

154ngroves commented 5 years ago

Buongiorno, sto utilizzando la versione 1.1.0 di spid-shibboleth-proxy-docker e devo effettuare dei controlli di coerenza nell'applicazione backend (https://github.com/italia/spid-shibboleth-proxy-docker/issues/16): in particolare devo controllare che alcuni elementi presenti nella request abbiano lo stesso valore dei corrispettivi presenti nella response. Esiste un modo per reperire la request in modo da effettuare questi controlli? Il controllo sulla validità della firma è a carico del docker? Ho inoltre riscontrato dei problemi con alcuni test, nel caso di attributi senza NameFormat il docker dovrebbe comunque consentirmi l'accesso, quello che succede invece è che l'accesso mi viene negato. Variando inoltre l'attributo IssueInstant in millisecondi, il docker dovrebbe garantirmi comunque l'accesso, ma questo mi viene impedito. Grazie.

psmiraglia commented 5 years ago

Esiste un modo per reperire la request in modo da effettuare questi controlli?

Purtroppo no in maniera nativa. Il caching della AuthRequest e' un meccanismo che deve essere costruito e implementato in base alle caratteristiche dell'ambiente.

Il controllo sulla validità della firma è a carico del docker?

Si

Ho inoltre riscontrato dei problemi con alcuni test, nel caso di attributi senza NameFormat il docker dovrebbe comunque consentirmi l'accesso, quello che succede invece è che l'accesso mi viene negato.

Se non ricordo male, questo e' un problema noto. Il mio collega @AntonioGiovanniSchiavone puo' darvi maggiori dettagli a riguardo.

Variando inoltre l'attributo IssueInstant in millisecondi, il docker dovrebbe garantirmi comunque l'accesso, ma questo mi viene impedito.

Non e' chiaro il problema. Un esempio?

154ngroves commented 5 years ago

Ho effettuato dei test con il seguente idp di test: https://github.com/italia/spid-saml-check Un caso di test prevede il tentativo di inviare una response con un IssueInstant comprendente anche i millisecondi. Il risultato atteso del test era un "OK", quindi il docker avrebbe dovuto comunque consentire l'accesso. Il test è fallito in quanto il docker ha impedito l'accesso al sistema in questa casistica.

154ngroves commented 5 years ago

Buongiorno @psmiraglia, avrei bisogno di sapere se il controllo sull'uguaglianza dell'attributo InResponseTo tra Request e Response viene effettuato automaticamente dal docker. Se così non fosse, per effettuare questa tipologia di validazione è opportuno creare un nuovo controllo all'interno del docker?

psmiraglia commented 5 years ago

Buongiorno @psmiraglia, avrei bisogno di sapere se il controllo sull'uguaglianza dell'attributo InResponseTo tra Request e Response viene effettuato automaticamente dal docker.

No. Questa è una questione aperta, tutt'ora in corso di discussione.

Se così non fosse, per effettuare questa tipologia di validazione è opportuno creare un nuovo controllo all'interno del docker?

Si, che poi sia all'interno del container o da qualche altra parte dell'architettura è una vostra scelta.

154ngroves commented 5 years ago

Buonasera, ho cercato all'interno del docker il meccanismo con cui vengono impostati i valori all'interno della request (Es. ID, IssueInstant) ma ho trovato solo il codice per la generazione di un template contenente dei valori "placeholder". @psmiraglia potresti cortesemente indicarmi dove e come avviene questo meccanismo di compilazione di ID e IssueInstant della request?

psmiraglia commented 5 years ago

potresti cortesemente indicarmi dove e come avviene questo meccanismo di compilazione di ID e IssueInstant della request?

Le AuthnRequest vengono generate a runtime da Shibboleth a seconda del SessionInitiator che viene invocato (es. /iam/Login1, /iam/Login27).

I SessionInitiator non sono altro che dei template di AuthnRequest che vengono definiti nel file /etc/shibboleth/shibboleth2.xml. Questo, viene generato durante il bootstrap del container (vedi How to define AttributeConsumingService elements).

Per vedere il prodotto finale, potete utilizzare il comando


$ docker exec -ti <CONTAINER ID> cat /etc/shibboleth/shibboleth2.xml
154ngroves commented 5 years ago

Ho capito, grazie. Sarei interessato anche a trovare un modo per intercettare l'AuthnRequest per effettuare le validazioni. Se per esempio dovessi validare l'attributo InResponseTo presente nella Response, avrei bisogno di confrontarlo con l'ID presente nella AuthnRequest. Esiste un modo per recuperare l'AuthnRequest generata a runtime e inviata da shibboleth?

psmiraglia commented 5 years ago

Esiste un modo per recuperare l'AuthnRequest generata a runtime e inviata da shibboleth?

Shibboleth non offre questa feature.

Per quanto possano sembrare attinenti, tengo a precisare che questo non e' uno spazio per richiedere assistenza su SPID, Shibboleth e sull'uso di Docker. Per SPID potete far riferimento a spid.tech@agid.gov.it mentre per Shibboleth e Docker, si faccia riferimento ai canali ufficiali.

154ngroves commented 5 years ago

Ti ringrazio per le indicazioni ma quello che volevo capire è come recuperare il valore di ID della Request per confrontarlo con l'attributo InResponseTo della Response e se utilizzando questo docker è possibile farlo. Attualmente utilizziamo un'applicazione nodejs per la validazione della response.

154ngroves commented 5 years ago

Buongiorno @psmiraglia Per quanto riguarda la seguente richiesta, riesci a fornirmi indicazioni al riguardo?

Ho effettuato dei test con il seguente idp di test: https://github.com/italia/spid-saml-check Un caso di test prevede il tentativo di inviare una response con un IssueInstant comprendente anche i millisecondi. Il risultato atteso del test era un "OK", quindi il docker avrebbe dovuto comunque consentire l'accesso. Il test è fallito in quanto il docker ha impedito l'accesso al sistema in questa casistica.

Grazie.