Auth Docker 1.0.0
ac044 opened this issue · 15 comments
Buonasera, abbiamo installato la versione 1.0.0 dello Spid Auth Docker e settato lo stesso in modalità di sviluppo.
Abbiamo registrato un service provider sul servizio fornito da Agid all'url https://idp.spid.gov.it:8080, ma provando a fare l'accesso il servizio ritorna sempre ad una pagina riportante la seguente dicitura:
Invalid Response - The response obtained from the Identity Provider is not valid.
Please check the returned authnContextClassRef and/or the returned attributes. The authnContextClassRef MUST be one of:
https://www.spid.gov.it/SpidL1
https://www.spid.gov.it/SpidL2
https://www.spid.gov.it/SpidL3
The returned attribute set MUST match the requested AttributeConsumingService..
Il service provider creato ha gli stessi attributi (AttributeConsumingService) riportati nel compose file docker-compose.yml.
La stessa procedura effettuata con la versione 0.4 non ha mai dato problemi di questo tipo.
Attendiamo gentilmente indicazioni su come ovviare all'issue, grazie.
Salve @ac044, il branch 1.x di SPID Auth Docker esegue dei controlli abbastanza stringenti sulla response ottenuta dall'identity provider.
Uno di questi e' il formato di authnContextClassRef. Purtroppo, questo viene ancora ritornato da idp.spid.gov.it nel formato urn:oasis:names:tc:SAML:2.0:ac:classes:Password. Questo, non passa le regole di validazione qui definite
Un workaround temporaneo potrebbe essere quello di modificare
<OR>
<Rule require="authnContextClassRef">https://www.spid.gov.it/SpidL1</Rule>
<Rule require="authnContextClassRef">https://www.spid.gov.it/SpidL2</Rule>
<Rule require="authnContextClassRef">https://www.spid.gov.it/SpidL3</Rule>
</OR>in
<OR>
<Rule require="authnContextClassRef">https://www.spid.gov.it/SpidL1</Rule>
<Rule require="authnContextClassRef">https://www.spid.gov.it/SpidL2</Rule>
<Rule require="authnContextClassRef">https://www.spid.gov.it/SpidL3</Rule>
<Rule require="authnContextClassRef">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</Rule>
</OR>Grazie per il suggerimento, effettivamente in questo modo si bypassa la verifica del formato di authnContextClassRef e l'autenticazione va a buon fine.
Fermo restando che questo workaround è temporaneo per la sola parte di test con lo SPID Auth Docker in modalità di sviluppo, impostando questo in modalità di produzione possiamo dare per assodato che la verifica della Response ottenuta dagli IDP di produzione sia effettivamente validata secondo
quanto previsto dalla procedura di verifica effettuata con l'IDP SPID Validator?
Attualmente noi per conto della Regione Calabria abbiamo utilizzato la versione 0.4.0 dello SPID Auth Docker, modificando il back-end di gestione della risposta degli IDP, ma vorremmo aggiornare il tutto alla versione 1.0.0, utilizzando però in questo caso il back-end di default impostato sullo stesso, sempre se lo stesso effettui i controlli su tutti i parametri previsti dalla verifica tecnica.
Una volta che lo SPID Auth Docker completa i controlli, vorremmo procedere con l'invio del pacchetto dati di interesse al nostro servizio di validazione finale dell'autenticazione.
Possiamo considerare valida la procedura descritta, ed affermare quindi che lo SPID Auth Docker rilasciato effettua tutti i controlli previsti dalla verifica tecnica, in maniera tale da procedere con l'aggiornamento dello stesso e l'implementazione di quanto descritto?
Grazie
Grazie per il suggerimento, effettivamente in questo modo si bypassa la verifica del formato di authnContextClassRef e l'autenticazione va a buon fine.
Ottimo
Fermo restando che questo workaround è temporaneo per la sola parte di test con lo SPID Auth Docker in modalità di sviluppo, impostando questo in modalità di produzione possiamo dare per assodato che la verifica della Response ottenuta dagli IDP di produzione sia effettivamente validata secondo quanto previsto dalla procedura di verifica effettuata con l'IDP SPID Validator?
Da specifiche (e da relativi avvisi) gli identity provider di produzione possono ritornare come authnContextClassRef solo i seguenti valori
https://www.spid.gov.it/SpidL1https://www.spid.gov.it/SpidL2https://www.spid.gov.it/SpidL3
Pertanto, in produzione non e' necessario eseguire il workaround.
Attualmente noi per conto della Regione Calabria abbiamo utilizzato la versione 0.4.0 dello SPID Auth Docker, modificando il back-end di gestione della risposta degli IDP, ma vorremmo aggiornare il tutto alla versione 1.0.0, utilizzando però in questo caso il back-end di default impostato sullo stesso, sempre se lo stesso effettui i controlli su tutti i parametri previsti dalla verifica tecnica.
L'app di backend fornita con lo SPID Auth Docker e' solo e solamente a scopo di esempio e pertanto non deve essere considerata un esempio normativo ne tanto meno production-ready. Il meccanismo di inoltro dell'autenticazione fra i branch 0.x e 1.x e' rimasto invariato (HTTP request header).
Una volta che lo SPID Auth Docker completa i controlli, vorremmo procedere con l'invio del pacchetto dati di interesse al nostro servizio di validazione finale dell'autenticazione.
Possiamo considerare valida la procedura descritta, ed affermare quindi che lo SPID Auth Docker rilasciato effettua tutti i controlli previsti dalla verifica tecnica, in maniera tale da procedere con l'aggiornamento dello stesso e l'implementazione di quanto descritto?
Riguardo i controlli da eseguire sulle risposte ottenute dagli identity provider, purtroppo non tutti possono essere eseguiti dal container (ovvero da Shibboleth SP). Pertanto, questi devono essere eseguiti lato backend.
Il meccanismo di inoltro dell'autenticazione fra i branch 0.x e 1.x e' rimasto invariato (HTTP request header).
Grazie per la risposta, ma è proprio questo punto che non ci è chiaro. Nell'inoltro dell'autenticazione,
alcuni parametri della response ottenuta dall'IDP non vengono inviati nell'HTTP request header.
In questo caso quindi non potremmo effettuare tutto il resto dei controlli imposti dalle regole tecniche SPID.
D'altro canto, modificando il back-end dello SPID Auth Docker, reindirizzando la response direttamente ad un servizio ad hoc sviluppato, pur ottenendo la SAMLResponse completa, perdiamo dei parametri fondamentali quali Id ed Issue Instant della Request, utili a validare alcuni parametri della SAMLResponse stessa.
Come possiamo intervenire quindi per far si che più parametri della SAMLResponse siano inviati tramite la procedura di inoltro per come attualmente strutturata ,al backend desiderato?
E' possibile oltre a quanto avviene ora, inviare anche tutta la SAMLResponse nell'header del backend?
Grazie per la risposta, ma è proprio questo punto che non ci è chiaro. Nell'inoltro dell'autenticazione,
alcuni parametri della response ottenuta dall'IDP non vengono inviati nell'HTTP request header.
In questo caso quindi non potremmo effettuare tutto il resto dei controlli imposti dalle regole tecniche SPID.
Riguardo la validazione del protocollo e del profilo SAML stiamo lavorando per includere il tutto all'interno del container in modo da lasciare all'utente solo le verifiche relative alla semantica delle informazioni ritornate (es. attributi, livello autenticazione, ecc.).
D'altro canto, modificando il back-end dello SPID Auth Docker, reindirizzando la response direttamente ad un servizio ad hoc sviluppato, pur ottenendo la SAMLResponse completa, perdiamo dei parametri fondamentali quali Id ed Issue Instant della Request, utili a validare alcuni parametri della SAMLResponse stessa.
Questa soluzione credo sia da escludere. Mettere in piendi lo SPID Auth Docker solo per generare le AuthnRequest mi sembra un overhead eccessivo.
Come possiamo intervenire quindi per far si che più parametri della SAMLResponse siano inviati tramite la procedura di inoltro per come attualmente strutturata ,al backend desiderato?
In modalita dev, il container mette a disposizione il target /whoami. Questo fa il dump delle inforazioni che vengono inviate all'app di backend. Per accederci basta settare il parametro target della query string a https://your.docker.host/whoami. Ad esempio
https://your.docker.host/iam/Login0?
target=https://your.docker.host/whoami&
entityID=https://idp.spid.gov.it
Dovreste ottenere una cosa simile a questa
Host: ********
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
DNT: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: ********
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: ********
Shib-Cookie-Name:
Shib-Session-ID: ********
Shib-Session-Index: ********
Shib-Session-Expires: 1546865132
Shib-Session-Inactivity: 1546866932
Shib-Identity-Provider: https://validator.spid.gov.it
Shib-Authentication-Method: https://www.spid.gov.it/SpidL1
Shib-Authentication-Instant: 2019-01-07T12:14:59Z
Shib-AuthnContext-Class: https://www.spid.gov.it/SpidL1
Shib-AuthnContext-Decl:
Shib-Assertion-Count:
Shib-Handler: https://********/iam
ADDRESS:
COMPANYNAME:
COUNTYOFBIRTH:
DATEOFBIRTH:
DIGITALADDRESS:
EMAIL:
EXPIRATIONDATE:
FAMILYNAME:
FISCALNUMBER: ********
GENDER:
IDCARD:
IVACODE:
MOBILEPHONE:
NAME: ********
PLACEOFBIRTH:
REGISTEREDOFFICE:
SPIDCODE:
Shib-Application-ID: default
REMOTE_USER:
In questo modo avete una visione completa della informazioni che possono essere inviate all'app di backend e quindi "tarare" i vostri controlli.
Pare che Shibboleth SP dia la possibilita' di accedere all'asserzione (XML raw) relativa alla sessione corrente. E' una cosa su cui dobbiamo ancora investigare. Nel frattempo, potete dare un'occhiata a
- https://wiki.shibboleth.net/confluence/display/SP3/Sessions (parametro
exportLocation) - https://wiki.shibboleth.net/confluence/display/SP3/AssertionExport
E' possibile oltre a quanto avviene ora, inviare anche tutta la SAMLResponse nell'header del backend?
Non credo che la cosa sia possibile. Suggerisco di dare un'occhiata al seguente thread sul tema
Pare che Shibboleth SP dia la possibilita' di accedere all'asserzione (XML raw) relativa alla sessione corrente. E' una cosa su cui dobbiamo ancora investigare. Nel frattempo, potete dare un'occhiata a
Nei commit psmiraglia@5dcc58a e psmiraglia@60968fe trovate un primo esperimento che sfrutta l'esportazione delle asserzioni. Questo fa si che le request inviate all'app di backend contengano anche i seguenti header
Shib-Assertion-Count: 01
Shib-Assertion-01: https://********/iam/GetAssertion?key=_e82e874318fa09d933a9097f25d8981a&ID=_39a7f0a5-f122-41f1-870a-7736798c2399
In questo modo, l'app di backend puo' ottenere l'asserzione in formato raw (facendo GET sull'URL salvato in Shib-Assertion-01) ed eseguire ulterioni validazioni. Ad esempio:
const shibAssertionCount = req.get('Shib-Assertion-Count');
const shibAssertionUrl = req.get(`Shib-Assertion-${shibAssertionCount}`);
request({
url: shibAssertionUrl,
strictSSL: false,
}, (err, res, body) => {
//
// make here your validation
//
});Nei commit psmiraglia/spid-auth-docker@5dcc58a e psmiraglia/spid-auth-docker@60968fe trovate un primo esperimento che sfrutta l'esportazione delle asserzioni. Questo fa si che le request inviate all'app di backend contengano anche i seguenti header
Abbiamo seguito le indicazioni riportate nei commit ed effettivamente ora nell'header sono presenti sia
lo Shib-Assertion-Count che lo Shib-Assertion-01, correttamente valorizzati e riportante quest'ultimo l'url da richiamare per la chiamata GET.
Facendo GET sull'url ricevuta però la risposta riporta sempre lo status code 403 - Forbidden.
Sapresti indicarci da cosa potrebbe dipendere? Sei riuscito ad ottenere effettivamente l'asserzione in formato raw?
Facendo
GETsull'url ricevuta però la risposta riporta sempre lo status code403 - Forbidden.
Sapresti indicarci da cosa potrebbe dipendere?
Il meccanismo di export delle asserzioni prevede un meccanismo di ACL (Access Control List) che viene pilotato dall'attributo exportACL dell'elemento <Sessions>. Questo prevede una lista di indirizzi IP (separati da spazio) autorizzati ad eseguire la GET (default 127.0.0.1).
Attualmente, exportACL viene valorizzato dalla variabile d'ambiente SERVER_NAME. Questo fa si che la GET sia autorizzata solo se proveniente dall'app di backend nello scenario di esempio.
Sei riuscito ad ottenere effettivamente l'asserzione in formato raw?
Lo scenario presente in example dovrebbe funzionare "AS IS". Dovreste vedere l'asserzione nei log prodotti dall'app di backend
// NOTE: This demonstrate how to fetch the assertion in order to perform
// extra checks. See:
// - https://wiki.shibboleth.net/confluence/display/SP3/AssertionExport
// - https://wiki.shibboleth.net/confluence/display/SP3/Sessions
const shibAssertionCount = req.get('Shib-Assertion-Count');
const shibAssertionUrl = req.get(`Shib-Assertion-${shibAssertionCount}`);
request({
url: shibAssertionUrl,
strictSSL: false,
}, (err, res, body) => {
console.log(body);
});In alternativa, potete utilizzare il comando docker exec come segue
$ docker exec -ti <BACKEND APP CONTAINER> apk add --update add curl
$ docker exec -ti <BACKEND APP CONTAINER> curl -k <URL FROM Shib-Assertion-01>Ad esempio
$ docker exec -ti a291f92e4878 apk add --update curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
(1/5) Installing ca-certificates (20171114-r3)
(2/5) Installing nghttp2-libs (1.32.0-r0)
(3/5) Installing libssh2 (1.8.0-r3)
(4/5) Installing libcurl (7.61.1-r1)
(5/5) Installing curl (7.61.1-r1)
Executing busybox-1.28.4-r1.trigger
Executing ca-certificates-20171114-r3.trigger
OK: 19 MiB in 28 packages
$ docker exec -ti a291f92e4878 curl -k "https://********/iam/GetAssertion?key=_671f0702a5dd4dd1ebdfae60a66d0503&ID=_f3280885-01d1-4405-9392-75524d5469ae"
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_f3280885-01d1-4405-9392-75524d5469ae" IssueInstant="2019-01-08T12:59:01Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://validator.spid.gov.it</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><ds:Reference URI="#_f3280885-01d1-4405-9392-75524d5469ae"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>eTsrvlzjRBO8c3/W1eHJLfZD4BBsGLmhvpO2/MPTVTE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>sETzlddQ7N2I9smgsQfVpOjhShTShhzdt9JRpKg3S6eAci8ca+66vkqBSjr2OiIIXuM3eJxhZH5SbjK6sHLJ920MDk8M1QXMpO9X6aCsmpYplMCYSJvJNajSStGf34xoYbpmR4NHWyAqjb8Q7pRm/SlmG109IJSrATdDzrs5w+D6LlSCJ7I2QMbiisq1jhQ/9jqQCyR8bWjULxzeIhDmg7ckQUymL4lIbGHo8WWiL98Fbsr4mlhl1HYro7i1PUOYYz1ErbxLvF6bit1Tv8g8+NG/qGb1qXviTMVTER8LzsgzRAJ6UQlrneuDn/QkcfkszTcrqNj61GUNY5LAVhNF/WEB0dXFaE6sibdk8hqmpPRr846Zdz//MLj4LKbPBNPq0pJD6eQA8pBNaxK13o3bBYNbY+cIZLgAmFZKsSXlAUXtFW69hpQjDGm1W/1NtUJL+8FwjzCsTSihgnhOWTOVXF4NEuksJVTyCKcBNEeNcXL+hwxpnKh7vqzPq1CWdcLKP0tQ5hWUVd0RHUDICtrdSmuFPlRbk4d+HFc7K0vbEBYEh1fYWpc20NTEQj8c1g7TeytMXl3ds1HoHR6CymoOxTtJ8FNr1h+LyueGoQCMS3k6TobUSM0ek4msADMDbaGJurmLvpHf5ml4jcH7YIgMPilTCSagKHpbttmtnomy4oU=</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIFkDCCA3igAwIBAgIJAPsdlzvQOm7MMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAklUMQ0wCwYDVQQIDARSb21lMQ0wCwYDVQQHDARSb21lMQ0wCwYDVQQKDARBZ0lEMQ0wCwYDVQQLDARBZ0lEMRIwEAYDVQQDDAlsb2NhbGhvc3QwHhcNMTgwOTI4MTIzNDUwWhcNMjEwOTI3MTIzNDUwWjBdMQswCQYDVQQGEwJJVDENMAsGA1UECAwEUm9tZTENMAsGA1UEBwwEUm9tZTENMAsGA1UECgwEQWdJRDENMAsGA1UECwwEQWdJRDESMBAGA1UEAwwJbG9jYWxob3N0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA6Un1wUkRKyXH9eJRnfdRvDFv4Nj+S4yA5hhnDjOG72ups7QLYMsHGMakYRtf9s9QMFE9FWQCtr3XazIFNb74cuQbS1SSvfjeER9iQG9XNxXjrZAQ080flSoFWcNevp8a9J4i3eFattqTTrqXebRKdzcc4dMuA4btSSGNtHG1a+nFp173BS8Bck8go/HrWnxUvicwcJF1UTkie/TBEFtd8PM+HKrp2YDr+RWGVGu4faZPaDs7m6enlXwR9YoHvIUGeRinVwGkqeV/uJBijyryxOoanIuaYrNX86CgQlcN1mpUxNRv/okcckskq4/BSWMTfn2BxFnrsbzwhC6IyetiJdGiSMJFmLEx3Oof8pGU1csQ3nFT3PLNaK87gSNnvb3mugbKmdq5hrmZIrFGei66LN9aLNTYi00tSd9lBQe5LftT3DAdH4FrcgRvfjzfq8/T0mp9R/oO0xjYq1HhyhJax/5FAtQQN17em6SV6rVb9D09aBPHlRA3jkRMyOjAPSXCJZ6egpM9EOEd1d9XkiKusqt8OQCJgu76XcU7cWLni/i0Rczfda965U6U3TDT1UYNocy+0PLv6hANMwYcshFu0INzgj7RUZiqxCWNDCvmekl4Q6ISGsoLnAuLEmKShJZ8LalVyp+yjn2SBKMW/W/e9u9bf1xKEP6Y3BEvrt8SzpECAwEAAaNTMFEwHQYDVR0OBBYEFEew5N5p5z20H0IXr/ahB86yZV+oMB8GA1UdIwQYMBaAFEew5N5p5z20H0IXr/ahB86yZV+oMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggIBAMMKVy905J+CUlRIkIJPQpoBtvJQe3TOk/z1NrMLBZBUXyM6gVBQV975AHQ7jX1/VM17DUypcAbGoNTUfdFJ1UEs1HlbUFqoTPuSIbpPm/l6ljw/+LdfGiGvThJD7yTzY6pMUYf0a1xXtFfyJbrGG6EW3TWlYF1liApWwGv95bEyBidqS84tiH6diF5yYfd0FfVp3DI/nJshWcmCaVXEcYxCXlNLi4GrIfj/HEjaqAotlXKMB0LXTrkXt10hdr2Tr80BKknT91J4wWL5zK6Pdt5uiTY/X4/zpc+iflp+bxWXnysPxkJr82XeXuwj1yxSFwlD/kKwo3b650I7/7UmjpAP0+US5Z5HWOD0e/W+dSqouPQSv0S87c2riaCSXQINeBcbsBPdm2wCwmEQXdcM9/Z+IMawazfa5qtPQiJJs2amF6Y3OlkxioEhYdimdGG01QR1ThSsbMU4CD2rXhMUAVB9yjGzUaWcABO7k0i+J3Pp9/enWdVTD1tfCs95jYonE9qaVJ1od8z09eUJI9VwfYtBPnpgR93mN6ERa1QrIHIQoQxR739yMPERUO2kz9X52qNU8KFBsbZ3nAjEVYnRaJ51UuFamiG9r7Sjog/8y/2QXr87F9xbF3ykGF8M9eISp/ev8EIrOSz+HIFcUsLq0gyW9mWXxMTUthdYztkQZkR8</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://validator.spid.gov.it">
_4f158986-da05-4fdf-9a5a-bb1cb9c691bb
</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_6fe5fcfdeb4765fc41d8eb6e116bf31d" NotOnOrAfter="2019-01-08T13:03:54Z" Recipient="https://********/iam/SAML2/POST"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2019-01-08T12:59:01Z" NotOnOrAfter="2019-01-08T13:03:54Z">
<saml:AudienceRestriction>
<saml:Audience>https://********</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2019-01-08T12:59:01Z" SessionIndex="_515c219f-2339-41c8-a030-3eb04b9422d9">
<saml:AuthnContext>
<saml:AuthnContextClassRef>https://www.spid.gov.it/SpidL1</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Alice</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="fiscalNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">TINIT-SCHNNG77M06H224U</saml:AttributeValue> </saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>@psmiraglia abbiamo installato lo Spid Auth Docker 1.0.0 sul server di produzione https://spid.regione.calabria.it ed il relativo metadata è su https://spid.regione.calabria.it/metadata
Le location sono quelle impostate di default dal docker, nel nostro caso quindi l'AssertionConsumerService è su (https://spid.regione.calabria.it/iam/SAML2/POST).
Prima di procedere alla richiesta di validazione del nuovo metadata, vorremmo essere sicuri che il comportamento del target /whoami sia garantito anche in modalità prod.
Puoi darci un cortese riscontro o eventualmente indicarci come procedere?
Abbiamo notato inoltre stasera che utilizzando il meccanismo di instaurazione della chiamata con gli IDP, stranamente questi rispondono, restituendo però l'errorCode (16ASSERTIONCONSUMERSERVICE NON CORRETTAMENTE VALORIZZATO).
E' possibile che sia stato pubblicato giusto oggi il vecchio metadata di cui era stata richiesta pubblicazione lo scorso dicembre?
Prima di procedere alla richiesta di validazione del nuovo metadata, vorremmo essere sicuri che il comportamento del target
/whoamisia garantito anche in modalità prod.
Puoi darci un cortese riscontro o eventualmente indicarci come procedere?
L'endpoint /whoami e' disponibile solo in modalita' dev. Se volete abilitarlo anche in produzione (a vostro rischio e pericolo) dovete modificate lo script docker-bootstrap.sh (ed i file coinvolti) qui
e qui
Abbiamo notato inoltre stasera che utilizzando il meccanismo di instaurazione della chiamata con gli IDP, stranamente questi rispondono, restituendo però l'errorCode (16ASSERTIONCONSUMERSERVICE NON CORRETTAMENTE VALORIZZATO).
A livello di sintassi sembra essere corretto. Giusto @AntonioGiovanniSchiavone?
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://spid.regione.calabria.it/iam/SAML2/POST"
index="0"
isDefault="true"/>E' possibile che sia stato pubblicato giusto oggi il vecchio metadata di cui era stata richiesta pubblicazione lo scorso dicembre?
Riguardo lo stato della pubblicazione del metadata dovete contattare @AntonioGiovanniSchiavone.
L'endpoint /whoami e' disponibile solo in modalita' dev. Se volete abilitarlo anche in produzione (a vostro rischio e pericolo) dovete modificate lo script docker-bootstrap.sh (ed i file coinvolti) qui
Perdonami forse ci siamo spiegati male, ma quello di cui volevamo essere sicuri è che impostando l'AssertionConsumerService su https://spid.regione.calabria.it/iam/SAML2/POST, nella location indicata riceviamo i parametri di interesse nell'header, tra i quali anche Shib-Assertion-Count e relativo Shib-Assertion con url per reperire l'Assertion, mediante i passaggi conosciuti.
Abbiamo notato inoltre che sul metadata, impostando l'AssertionConsumerService con index 0, non riusciamo a impostare l'AttributeConsumingService anch'esso a 0: in questo caso infatti il docker va in esecuzione ma il web server Apache si riavvia di continuo rendendolo di fatto irraggiungibile.
Abbiamo notato inoltre che sul metadata, impostando l'AssertionConsumerService con index 0, non riusciamo a impostare l'AttributeConsumingService anch'esso a 0: in questo caso infatti il docker va in esecuzione ma il web server Apache si riavvia di continuo rendendolo di fatto irraggiungibile.
Errore di configurazione nostro perdonaci, se puoi attendiamo conferma sulla prima parte della richiesta.
Perdonami forse ci siamo spiegati male, ma quello di cui volevamo essere sicuri è che impostando l'AssertionConsumerService su https://spid.regione.calabria.it/iam/SAML2/POST, nella location indicata riceviamo i parametri di interesse nell'header, tra i quali anche Shib-Assertion-Count e relativo Shib-Assertion con url per reperire l'Assertion, mediante i passaggi conosciuti.
Se ho capito bene, mi state chiedendo se su https://spid.regione.calabria.it/iam/SAML2/POST ricevete i request header che vengono mostrati da /whoami. Se cosi' fosse, la risposta e' no.
Sulla Location di AssertionConsumerService (https://spid.regione.calabria.it/iam/SAML2/POST) riceverete dagli IdP SPID una SAML response. Questa viene "macinata" da shibboleth il quale effettua tutti i controlli del caso ed estrae tutte le informazioni per generare i request header. Questi vengono usati per inoltrare la SAML response al backend sotto forma di GET (tramite reverse proxy).
Questa e' la configurazione del reverse proxy che implementa quanto descritto
Questo invece e' un estratto del codice dell'app di backend (di test) che estrae i request header dalle GET fatte sull'endpoint /login
il quale e' stato specificato nel parametro target della query string per iniziare il flusso di autenticazione
https://spid.regione.calabria.it/iam/Login0?
target=https://spid.regione.calabria.it/login&
entityID=[...]
Abbiamo notato inoltre che sul metadata, impostando l'AssertionConsumerService con index 0, non riusciamo a impostare l'AttributeConsumingService anch'esso a 0: in questo caso infatti il docker va in esecuzione ma il web server Apache si riavvia di continuo rendendolo di fatto irraggiungibile.
A giudicare dal vostro metadata, avete lanciato il container definendo le seguenti variabili d'ambiente
ACS_INDEXES: '1'
ACS_1_LABEL: 'Ecosistema Sanità Calabria'
ACS_1_ATTRS: 'fiscalNumber'
quello che mi state dicendo e' che se queste vengono modificate in
ACS_INDEXES: '0'
ACS_0_LABEL: 'Ecosistema Sanità Calabria'
ACS_0_ATTRS: 'fiscalNumber'
si scassa tutto. Confermate?
si scassa tutto. Confermate?
No, refuso nostro in fase di configurazione del docker, perdonaci per la segnalazione errata.
In ogni caso in ambiente di test non riusciamo a testare il tutto con ACS_INDEXES: '0', in quanto nella configurazione dell'IDP di test su https://idp.spid.gov.it:8080/ non si riesce a settare l'AttributeConsumingService con index 0.
Sulla Location di AssertionConsumerService (https://spid.regione.calabria.it/iam/SAML2/POST) riceverete dagli IdP SPID una SAML response. Questa viene "macinata" da shibboleth il quale effettua tutti i controlli del caso ed estrae tutte le informazioni per generare i request header. Questi vengono usati per inoltrare la SAML response al backend sotto forma di GET (tramite reverse proxy).
Ok sei stato chiaro, noi comunque nel file z20-auth-proxy.conf.prod abbiamo anche aggiunto ShibRequestSetting exportAssertion 1 per ottenere l'url di interesse per effettuare i controlli sulla parte di Assertion.
Grazie ancora
@ac044 Buongiorno,
noi abbiamo avuto gli stessi problemi e abbiamo seguito questa issue per realizzare i controlli sull'Assertion nella backend-app.
Attualmente ci manca di verificare che l'attributo inResponseTo sia uguale all'id della request, ma non è possibile recuperare la request nella backend app (#26).
Voi dove siete intervenuti per fare questo controllo dato che il docker non lo effettua?
Grazie.