SPID Metadata Signer

Ho caricato su GitHub Italia, SPID Metadata Signer.
Il tool semplifica e automatizza l’utilizzo di XmlSecTool, per la firma del Metadata SAML di SPID, principalmente per Service Provider ma anche per Identity Provider e Attribute Authority.
E’ in fase di review il tool online per la creazione di metadata SAML compliant a SPID.

Link al repository: https://github.com/italia/spid-metadata-signer
Link alla release 1.0: https://github.com/italia/spid-metadata-signer/releases/tag/v1.0

Per vedere un esempio di metadata SAML SPID:
Versione non firmata: https://github.com/italia/spid-metadata-signer/blob/master/metadata/metadata-in/agid-spid-esempio-metadata.xml
Versione firmata: https://github.com/italia/spid-metadata-signer/blob/master/metadata/metadata-out/agid-spid-esempio-metadata-signed.xml

3 Mi Piace

Ottimo! Ricordati di farmi una PR per aggiungerlo anche alla pagina SPID sul sito

1 Mi Piace

Ottimo lavoro, @umbros! Sto cercando di portare ‘xmlsectool’ anche dentro Homebrew. Qui la PR: https://github.com/Homebrew/homebrew-core/pull/11812

Ultime modifiche e dovremmo esserci! :slight_smile:

1 Mi Piace

Grande! Lo integriamo subito subito :smiley:

xmlsectool è ora presente in homebrew.

Per installarlo basta eseguire “brew install xmlsectool:grin:

Formula: https://github.com/Homebrew/homebrew-core/blob/master/Formula/xmlsectool.rb

E’ probabilmente una low-pri ma per fixare #1, #2 e #3 (+ rimuovere dipendenze esterne come Java, unzip, xmlsectool, etc…) stavo pensando di riscrivere il tool utilizzando golang e nessuna lib “esterna”.

Purtroppo non sono molto pratico dei dettagli tecnici di SPID. Da quanto ho capito il tool dovrebbe prendere in input:

  • XML da firmare
  • chiave (.key)
  • password della chiave (se presente, si spera di si :grin:)
  • certificato (.crt)

e generare in output un file XML firmato usando http://www.w3.org/2001/04/xmldsig-more#rsa-sha256. Non mi e’ chiaro se l’XML in input debba contenere gia’ l’elemento Signature o meno e se ci siano solo particolari elementi da firmare (ID?) o no. Mi son perso altro?

Saluti

Ciao @guido.iaquinti lo script in realtà è solo al fine di utilizzare XmlSecTool.
Mercoledì verrà rilasciato un tool completo in python che crea e firma il metadata SPID senza tool esterni. Magari se vuoi realizzare la versione golang di quello possiamo parlarne e appena rilascio ti spiego tutto.

Ciao e grazie per la collaborazione

Ottimo! Il linguaggio non e’ importante, la mia idea era proprio di rimpiazzare anche xmlsectool ed avere uno static bin. Aspetto la nuova release allora.

Buona giornata!

Ciao @guido.iaquinti si l’idea è quella di rilasciare un tool che non complichi troppo la vita in quanto a dipendenze e sia semplice ed immediato da utilizzare. A ciò si affiancheranno anche dei tool online.
A presto :smiley:

Scusa, dicevi mercoledì, so che si va sempre lunghi ma per caso l’hai rilasciato e sono io che non lo trovo?
Volevo farne uno per win in .NET ma se c’è questo in python lascio stare.

Ciao Gibson,
c’è stato un delay e rilascio questa settimana.

Grazie

1 Mi Piace

Salve @umbros , volevo esporre una problematica che si è presentata oggi e che potrebbe essere d’aiuto anche ad altri. Ero alle rese con la rigenerazione del metadata.xml per la scadenza del nostro certificato e stavo utilizzando i due progetti di creazione metadata.xml e firma.
Avendo un pc nuovo, e avendo quindi installato tutti i software da zero, mi sono imbattuto in un problema abbastanza fastidioso che mi ha rubato parecchio tempo.

Il problema era legato ad una eccezzione rilanciata da xmlsectool, il quale mi diceva:

Firma del metadata: metadata/metadata-in/metadata.xml INFO XMLSecTool - Reading XML document from file 'metadata/metadata-in/metadata.xml' INFO XMLSecTool - XML document parsed and is well-formed. ERROR XMLSecTool - Unknown error java.lang.ArrayIndexOutOfBoundsException: 1 at org.cryptacular.asn.OpenSSLPrivateKeyDecoder.decryptKey(OpenSSLPrivateKeyDecoder.java:44) ~[cryptacular-1.0.jar:na] at org.cryptacular.asn.AbstractPrivateKeyDecoder.decode(AbstractPrivateKeyDecoder.java:22) ~[cryptacular-1.0.jar:na] at org.cryptacular.util.KeyPairUtil.decodePrivateKey(KeyPairUtil.java:423) ~[cryptacular-1.0.jar:na] at org.opensaml.security.crypto.KeySupport.decodePrivateKey(KeySupport.java:221) ~[opensaml-security-api-3.2.0.jar:na] at org.opensaml.security.crypto.KeySupport.decodePrivateKey(KeySupport.java:200) ~[opensaml-security-api-3.2.0.jar:na] at net.shibboleth.tool.xmlsectool.CredentialHelper.getFileBasedCredentials(CredentialHelper.java:81) ~[xmlsectool-2.0.0.jar:na] at net.shibboleth.tool.xmlsectool.XMLSecTool.getCredential(XMLSecTool.java:889) ~[xmlsectool-2.0.0.jar:na] at net.shibboleth.tool.xmlsectool.XMLSecTool.main(XMLSecTool.java:148) ~[xmlsectool-2.0.0.jar:na]

Dopo diverse peripezie ho scoperto che la causa era nella lettura del file CRT, avente password, prodotto con openssl 1.1.0g openssl req -x509 -sha512 -days 365 -newkey rsa:2048 -keyout nome-chiave.key -out nome-certificato.crt

Recuperata da un collega la vecchia configurazione, e fatte le dovute verifiche , ho accertato che creando i certificati con openssl1.0.2.g non si incorre nell’errore sopra menzionato.

A presto

1 Mi Piace