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

risorsa da specificare in exportACL di shibboleth2.xml.tpl #27

Open 154ngroves opened 5 years ago

154ngroves commented 5 years ago

Buongiorno, Abbiamo seguito quanto specificato all'interno della issue https://github.com/italia/spid-shibboleth-proxy-docker/issues/16 per recuperare gli assertion in formato raw. Nel nostro scenario lo spid-shibboleth-proxy-docker e l'app di backend sono all'interno di webapp nell'infrastruttura Microsoft Azure. Per abilitare l'accesso della webapp alla risorsa /iam/getAssertion abbiamo abilitato nelle exportACL l'indirizzo ip che tenta di accedere a tale risorsa, recuperato dall'access log di apache. Può essere che questo indirizzo IP faccia riferimento al servizio shibboleth contenuto nel docker? Il problema che riscontriamo è che su Azure questo IP cambia a fronte di deploy della wepapp ed è quindi necessario modificare manualmente il set di IP abilitati. Se tale IP fa riferimento a shibboleth è possibile renderlo statico? Oppure è possibile abilitare una classe di IP anzichè il singolo indirizzo?

Grazie per l'assistenza.

psmiraglia commented 5 years ago

Se tale IP fa riferimento a shibboleth è possibile renderlo statico?

La gestione degli indirizzi IP in Azure e' OT rispetto al repository.

Oppure è possibile abilitare una classe di IP anzichè il singolo indirizzo?

Citando la definizione di exportACL

The set of requesters allowed to query the SP for assertions using the mechanism described in the Assertion Export topic. This should almost always be left as 127.0.0.1 (or ::1 for IPv6) to prevent third parties from viewing sensitive data about users. No other security mechanism is currently supported. IPv6 addresses must be provided in the non-dotted format with lower case letters and without padding '0's. E.g. 2001:620:0:40:c62c:3ff:abc:123

Un possibile trick (mai provato) potrebbe essere quello di inserire all'interno del container una semplice app che espone un endpoint (es. /getassertion) che fa da proxy verso

Shib-Assertion-01: https://********/iam/GetAssertion?key=_e82e874318fa09d933a9097f25d8981a&ID=_39a7f0a5-f122-41f1-870a-7736798c2399

Dato che in questo caso le richieste provengono dalla app che gira al fianco di shibd, queste risultano provenire da localhost (o 127.0.0.1).