Buongiorno.
Lo scenario da lei delineato è invero abbastanza comune: un singolo Service Provider (SP) che ha più servizi gestiti a loro volta da fornitori tecnologici diversi. La soluzione di ciascuno di questi fornitori è dotata di una chiave privata differente (non necessariamente diversa da SP a SP) con cui il fornitore sigilla le request per il/i servizio/i fornito/i per conto del SP.
Seguendo la normativa europea di riferimento relativa ai certificati elettronici (ETSI EN319-412, in 5 parti), che a sua volta richiama lo standard internazionale ITU-T X.520, l’estensione commonName
non è adatta allo scopo da lei indicato. La normativa prevede, infatti, che tale estensione identifichi, nell’ambito d’uso del certificato o del directory service, il soggetto del certificato: cioè il SP o l’Aggregatore. In SAML e, perciò, anche nell’ambito SPID, l’EntityID è l’identificativo di riferimento di tali soggetti, proprio perché è il nome con cui ciascun ente della federazione si presenta, “tecnicamente,” verso gli altri.
L’Avviso SPID №29 per i SP (così come, mutatis mutandis, l’Avviso SPID №19 per gli Aggregatori) non vieta l’utilizzo di altre estensioni “X.509,” purchè queste non siano in antitesti con la normativa SPID.
Bisogna anche considerare che non deve esserci alcuna presunzione di corrispondenza uno-a-uno tra i servizi nel metadatada SAML (<AttributeConsumingService>
) e i certificati di sigillo delle request (<KeyDescriptor>
con uso signing
), perciò l’associazione dei certificati ai servizi, non essendo in generale monodroma, non andrebbe etichettata in maniera così rigida sui certificati: cosa succederebbe se, a un certo punto, il medesimo certificato venisse usato per più servizi/nodi diversi?
Come già segnalato, gli Aggregatori full (ex Avviso SPID №19) e, più in generale, vari fornitori tecnologici, riusano il proprio certificato per più soggetti (Aggregati o SP) diversi.
Tutto ciò premesso, per distinguere fra loro eventuali certificati multipli utilizzati dallo stesso soggetto (SP, Aggregatore full o Aggregato light che sia), inclusa la possibilità di associarli a nodi/servizi diversi, consigliamo di adottare diverse strategie alternative ― tutte, peraltro, già previste in tal senso dagli standard tecnici:
- uno o più tra i tag
<KeyName>
o <X509SubjectName>
nel metadata SAML stesso (discendenti del tag <KeyDescriptor>
) — come previsto da standard XML-DSIG, l’associazione avverrebbe così nel metadata anziché nel certificato.
- estensione
uniqueIdentifier
nel SubjectDN
— da norma X.520, disambigua “oggetti” diversi (i servizi SPID) nell’ambito del medesimo soggetto del certificato (un SP o Aggregato);
- estensione
dnQualifier
nel SubjectDN
— da norma X.520, serve a disambiguare lo stesso soggetto del certificato (SP o Aggregato) in contesti con directory service diversi (assimilabili ai diversi nodi SAML o a partner tecnologici multipli);
-
SKI (Subject Key Identifier) — l’identificativo unico della chiave del soggetto;
- estensione
serialNumber
del certificato (non quella nel SubjectDN
) — il “numero seriale” vero e proprio del certificato;
-
hash del certificato — il modo naturale di identificare e distinguere biunivocamente più evidenze informatiche, anche al di fuori dell’ambito di riferimento.
Di tutte queste soluzioni, quella che adotterei nel suo caso è la prima in quanto, volendo associare un certificato ad un servizio (AsCS), l’associazione è fatta nel metadata stesso e consente anche di ripetere più volte lo stesso identificativo qualora questo sia associato a diversi nodi/servizi.