Migrazione dati da una precedente versione shib IdP - Cronologia

Malavolti@garr.it: /* Verifica della configurazione */

2024-10-30T10:13:42Z

Verifica della configurazione

← Versione meno recente		Versione delle 12:13, 30 ott 2024
Riga 19:		Riga 19:
	Prima di operare a livello di dns e rendere l'idp ufficialmente operativo consigliamo di effettuare una fase di test lavorando in locale e modificando il file <code>/etc/host</code> del proprio computer.		Prima di operare a livello di dns e rendere l'idp ufficialmente operativo consigliamo di effettuare una fase di test lavorando in locale e modificando il file <code>/etc/host</code> del proprio computer.

	Questo permetterà di fare tutti i test mantenendo ancora operativo il precedente idp.		Questo permetterà di fare tutti i test mantenendo ancora operativo il precedente idp, ad esempio:

			* test persistent-id/eduPersonTargetedID: il valore rilasciato dall'IdP in produzione e dall'IdP nuovo su cui si migra DEVE essere identico per entrambi

	<br />		<br />

Malavolti@garr.it il 10:07, 30 ott 2024

2024-10-30T10:07:28Z

← Versione meno recente		Versione delle 12:07, 30 ott 2024
Riga 4:		Riga 4:

	*entityID		*entityID
	*certificati (autofirmati) inclusi nei metadata (da non confondere con certificati SSL per il web)		*certificati (autofirmati) inclusi nei metadata (da non confondere con certificati SSL per il web) e loro segreti ==> intera cartella <code>credentials/</code>
	*attribute-resolver.xml		*<code>conf/attribute-resolver.xml</code>
	*attribute-filter.xml		*<code>conf/attribute-filter.xml</code>
			*<code>conf/saml-nameid.properties</code>
			*<code>conf/ldap.properties</code>
	*eventuali configurazioni verso database		*eventuali configurazioni verso database
	*eventuale database dei persistent-id (se presente)		*eventuale database dei persistent-id (se presente)
	*eventuali configurazioni di speciali relying-party		*eventuali configurazioni di speciali relying-party
			*eventuali configurazioni aggiuntive al file <code>conf/services.xml</code>

	La lista non è esaustiva e dipende chiaramente dalla singola installazione.		La lista non è esaustiva e dipende chiaramente dalla singola installazione.

Malavolti@garr.it il 14:45, 22 ott 2024

2024-10-22T14:45:51Z

← Versione meno recente		Versione delle 16:45, 22 ott 2024
Riga 20:		Riga 20:
	<br />		<br />

	=== Backchannel: si o no? ===		===Backchannel: si o no?===
	Sulla Documentazione di Shibboleth IDP troviamo scritto:		Sulla Documentazione di Shibboleth IDP troviamo scritto:

	* https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199500736/SecurityAndNetworking		*https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199500736/SecurityAndNetworking
	* https://shibboleth.atlassian.net/wiki/spaces/IDP30/pages/2495381844/SecurityAndNetworking (riportato per segnalare quanto era già valido dalla v3)		*https://shibboleth.atlassian.net/wiki/spaces/IDP30/pages/2495381844/SecurityAndNetworking (riportato per segnalare quanto era già valido dalla v3)

	==== Back-Channel Support (v5.x) ====		====Back-Channel Support (v5.x)====
	''Historically, Shibboleth IdP deployments operated with a second HTTP connector for SOAP requests from Service Providers. This connector by convention usually listened on port 8443. The separate port was used primarily because the connector generally relied on client certificate authentication at the TLS layer to authenticate requests from SPs. It's possible to host these SOAP services on the same port as the rest of the IdP's services and this is STRONGLY RECOMMENDED nowadays, but this topic focuses on the "why" aspect.''		''Historically, Shibboleth IdP deployments operated with a second HTTP connector for SOAP requests from Service Providers. This connector by convention usually listened on port 8443. The separate port was used primarily because the connector generally relied on client certificate authentication at the TLS layer to authenticate requests from SPs. It's possible to host these SOAP services on the same port as the rest of the IdP's services and this is STRONGLY RECOMMENDED nowadays, but this topic focuses on the "why" aspect.''

	==== Back-Channel Use Cases (v5.x) ====		====Back-Channel Use Cases (v5.x)====
	''Most newer SAML-only deployments do not need to support the back channel (at all, port notwithstanding. While there are a range of features that rely on the back channel, and probably more in the future, basic use of the IdP for SAML-based SSO does not require it. That said, the following features require a back channel, along with a brief explanation of why you might need them:''		''Most newer SAML-only deployments do not need to support the back channel (at all, port notwithstanding. While there are a range of features that rely on the back channel, and probably more in the future, basic use of the IdP for SAML-based SSO does not require it. That said, the following features require a back channel, along with a brief explanation of why you might need them:''

Riga 49:		Riga 49:

	- 1 per "encryption"		- 1 per "encryption"



Riga 62:		Riga 63:
	<md:Extensions>		<md:Extensions>
	<shibmd:Scope regexp="false">shib-idp-dev.aai-test.garr.it</shibmd:Scope>		<shibmd:Scope regexp="false">shib-idp-dev.aai-test.garr.it</shibmd:Scope>
	<mdui:UIInfo ~~xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"~~>		<mdui:UIInfo>
	<mdui:DisplayName xml:lang="en">Shibboleth IdP DEV</mdui:DisplayName>		<mdui:DisplayName xml:lang="en">Shibboleth IdP DEV</mdui:DisplayName>
	<mdui:Description xml:lang="en">Identity Provider of Shibboleth IdP DEV</mdui:Description>		<mdui:Description xml:lang="en">Identity Provider of Shibboleth IdP DEV</mdui:Description>

Malavolti@garr.it il 14:43, 22 ott 2024

2024-10-22T14:43:20Z

Mostra modifiche

Monticini@garr.it: Creata pagina con "Queste istruzioni sono utili nel caso sia stata installata una nuova versione di Shibboleth Idp e sia necessario riconfigurarla per sostituire un Identity Provider già regist..."

2024-02-14T11:37:38Z

Creata pagina con "Queste istruzioni sono utili nel caso sia stata installata una nuova versione di Shibboleth Idp e sia necessario riconfigurarla per sostituire un Identity Provider già regist..."

Nuova pagina

Queste istruzioni sono utili nel caso sia stata installata una nuova versione di Shibboleth Idp e sia necessario riconfigurarla per sostituire un Identity Provider già registrato nella Federazione IDEM.

Dati coinvolti nella migrazione:

* entityID
* certificati (autofirmati) inclusi nei metadata (da non confondere con certificati SSL per il web)
* attribute-resolver.xml
* attribute-filter.xml
* eventuali configurazioni verso database
* eventuale database dei persistent-id (se presente)
* eventuali configurazioni di speciali relying-party

La lista non è esaustiva e dipende chiaramente dalla singola installazione.

=== Verifica della configurazione ===
Prima di operare a livello di dns e rendere l'idp ufficialmente operativo consigliamo di effettuare una fase di test lavorando in locale e modificando il file <code>/etc/host</code> del proprio computer.

Questo permetterà di fare tutti i test mantenendo ancora operativo il precedente idp.