Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 1 di 16 28 marzo 2014 Specifiche Tecniche Interfacce Esterne Tutti i diritti riservati. Proprietà INSIEL SpA. Pag. 1 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 2 di 16 28 marzo 2014 Compendio: Il presente documento espone le specifiche tecniche per l’utilizzo delle Intefacce Esterne del sistema loginfvg, realizzato per la gestione dei meccanismi di accesso controllato alle risorse (applicazioni/servizi/funzionalità). Riferimenti: Modello di Gestione ModelloGFID_V1.5.pdf Federata delle Identità Digitali (GFID): SPCoop- Security Assertion Markup Language: saml-core-2.0-os.pdf Versione 1.0 Data 28.03.2014 Principali modifiche rispetto alla versione precedente precedente Prima versione Pag. 2 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 3 di 16 28 marzo 2014 INDICE 1. Introduzione ...................................................................................................................................................................................... 4 1.1. Premessa............................................................................................................................................................................................... 4 1.2. Abbreviazioni e definizioni ................................................................................................................................................................... 4 1.3. Gestione del documento...................................................................................................................................................................... 4 2. Il sistema loginfvg ............................................................................................................................................................................ 5 2.1. ll protocollo SAML ................................................................................................................................................................................ 6 2.2. Componenti del sistema loginfvg ........................................................................................................................................................7 2.3. Utilizzo dei Metadata .......................................................................................................................................................................... 14 Pag. 3 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 4 di 16 28 marzo 2014 1. Introduzione 1.1. Premessa Il presente documento espone le specifiche tecniche del sistema loginfvg realizzato per la gestione dei meccanismi di identificazione utente, certificazione attributi e accesso ai servizi applicativi utilizzando le specifiche SAML2 e in accordo al modello GFID normato da DigitPA. 1.2. Abbreviazioni e definizioni Il significato della maggior parte di abbreviazioni verrà dato nel corpo del documento stesso. Riportiamo comunque nella seguente tabella le abbreviazioni più utilizzate nel documento: AA Attribute Authority GFID Gestione Federata Identità Digitali IDP Identity Provider SP Service Provider SAML Secure Assertion Markup Language loginfvg Sistema di identificazione della Regione Autonoma FVG CNS Carta Nazionale dei Servizi PEP Policy Decision Point: componente che controlla l’accesso ad una risorsa in base alle regole (policy) definite SSO Single Sign-On 1.3. Gestione del documento La gestione del presente documento spetta alle risorse della Divisione Integrazione e Architetture - Area Architetture. Pag. 4 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 5 di 16 28 marzo 2014 2. Il sistema loginfvg loginfvg è un sistema di gestione e federazione dell’Identità digitale pensato per controllare l’accesso ai servizi in modalità Single Sign On, in grado di garantire i tre principi fondamentali della sicurezza informatica: • Confidenzialità, Confidenzialità intesa come la capacità di un sistema di rendere inintelligibile un messaggio a chi non è autorizzato. Di solito si utilizza la crittografia, ma è l’identità digitale che ha in sé le credenziali necessarie per fare ciò; • Integrità, Integrità intesa come la capacità di un sistema di garantire che il messaggio non sia stato alterato. Associato a tecnologie di firma elettronica, garantisce l’identità digitale del mittente; • Disponibilità, Disponibilità intesa come la possibilità di poter accedere alle informazioni nel momento in cui se ne ha bisogno. Per identità digitale si intende la rappresentazione elettronica di un set di asserzioni fatte da un soggetto digitale riguardo se stesso o un altro soggetto. Un’identità digitale è articolata in due parti: • Chi uno è (identità) • Le credenziali che ognuno possiede (gli attributi di tale identità) Le credenziali corrispondono ad un set di proprietà che possono differire molto in funzione dell’utilizzo che se ne intende fare. Pag. 5 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 6 di 16 28 marzo 2014 2.1. ll protocollo SAML Per la gestione e la federazione delle identità digitali esistono diversi standard. Tra questi, SAML (Secure Assertion Markup Language) è il protocollo maggiormente utilizzato per le federazioni di identità digitale basate su browser web, in particolare nell’ambito del businessto-business. Il predominio sul mercato di SAML ha provocato, tra l’altro, il ricongiungimento con Liberty ID-FF, incluso nella versione SAML 2.0. SAML è un framework basato su XML prodotto da OASIS Security Services Technical Committee che consente lo scambio di informazioni per l’autenticazione e per l’autorizzazione fra reti e siti web federati. SAML è uno standard informatico per lo scambio di dati di autenticazione e autorizzazione, dette Asserzioni, tra domini di sicurezza distinti (tipicamente un Identity Provider e un Service Provider): il formato delle asserzioni SAML è basato su XML. Il problema principale che SAML cerca di risolvere è quello del Web Single Sign-On (SSO) tra entità appartenenti a organizzazioni e domini di sicurezza distinti con lo scopo di gestire una identità federata. SAML permette di implementare, ad esempio, soluzioni di SSO che consentano agli utenti di visitare diversi siti web accedendo alle risorse protette in essi contenuti, senza dover fornire ogni volta le proprie credenziali. Oltre a questo, SAML rende possibile includere informazioni di sicurezza in documenti usati nelle transazioni d'affari. SAML permette alle “business entities” di emettere “assertions” relative a identità, attributi, e diritti di un subject indirizzate ad altre entità, come ad esempio un socio di una compagnia o un’ altra enterprise application. I vantaggi di SAML sono molteplici: • l’indipendenza dalla piattaforma utilizzata; • non è più necessario mantenere sincronizzate le informazioni utente tra le diverse directory. Ogni dominio gestisce gli attributi necessari al contesto d’uso; • miglioramento dell’esperienza online per l’utente finale, fornendo semplicità e sicurezza delle informazioni introdotte; • riduzione del costo d’amministrazione per i service provider, poiché l’atto di autenticazione può essere riusato senza bisogno di mantenere le informazioni d’account; • riduzione del rischio di trasferimento delle informazioni tramite meccanismi di sicurezza come firme digitali (XML Signature), cifratura (XML Encryption), crittografia (SSL e TLS), codifica, etc.. Pag. 6 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 7 di 16 28 marzo 2014 Le asserzioni SAML contengono pacchetti d’informazioni sicure scambiati tra autorità SAML e utilizzati per prendere decisioni di access control. Ogni asserzione può contenere uno o più costrutti SAML chiamati statement. Esistono tre tipi di statement: • Authentication statement: dichiara se il soggetto è stato riconosciuto in base alla tipologia di credenziali presentate e da chi, nonché l’istante in cui è stato rilasciato lo statement; • Attribute statement: dichiara che ad un soggetto sono associati determinati attributi e quale ne è il valore; • Authorization Decision statement: dichiara se il soggetto ha l’autorizzazione ad effettuare determinate azioni sulla risorsa (applicazione/servizio/etc.) in base alle proprie credenziali, agli attributi posseduti in quel determinato istante e quindi contenute nel portafoglio delle asserzioni costruito e ad altre eventuali regole di accesso definite dal Policy Decision Point (PEP). 2.2. Componenti del sistema loginfvg Ad ognuno degli statement definiti nel protocollo SAML è possibile associare un’entità o server, prevista negli standard per la federazione dell’Identià digitale; tali entità sono state definite in loginfvg e, di seguito, ne viene data una prima definizione, per identificarne il ruolo all’interno del processo di accesso ad una risorsa (servizio, per comodità, nel seguito): • Identity Provider: Provider è il componente responsabile della certificazione dell’identità degli utenti; solo gli utenti noti all’IdP possono accedere al servizio. • Attribute Authority: Authority è il componente in grado di certificare gli attributi degli utenti, questi attributi possono essere o meno organizzati in un profilo; ogni servizio richiede un certo insieme di attributi, certificati o meno da una AA, di cui l’utente deve disporre per poter fruire del servizio/risorsa/applicazione. Le AA possono essere sia interne che esterne al dominio; loginfvg, oltre ad implementare una propria AA, è in grado di svolgere il ruolo di Profile Authority (è l’entità incaricata della gestione dei profili dell’utente), mappando le Attribute Authority esterne federate che certificano gli attributi dell’utente. Inoltre è stata rilasciata una applicazione web in grado di svolgere il ruolo di Attribute Authority wrapper: tale applicazione permette ad un sistema che è in grado di certificare attributi ma che non “parla” SAML, di presentarsi come una AttributeAuthority, facendosi carico del dialogo basato su Asserzioni e interfacciando il sistema erogatore tramite un webservice standard. • Service Provider: Provider è l’authority che si occupa dell’autorizzazione all’accesso ad un servizio; verifica che l’utente sia stato riconosciuto da un IdP e disponga degli attributi necessari per accedere al servizio richiesto interfacciandosi con il Policy Decision Point. Pag. 7 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 8 di 16 28 marzo 2014 Ognuna delle entità descritte può essere interrogata singolarmente all’interno di un processo che descriva la modalità di accesso ad un servizio. Per interrogare l’Identity Provider (IdP) l’applicazione deve utilizzare una AuthenticationRequest, AuthenticationRequest passata come parametro di un’http request inoltrata con metodo POST; la request SAML va firmata, codificata in Base64 e passata come valore del campo SAMLRequest SAMLRequest. Request L’IdP di loginfvg mette a disposizione dell’utente varie modalità di riconoscimento: • Tramite username e password; le credenziali di questo tipo possono essere associate ad un account anonimo o ad una identità digitale; • Tramite smartcard CNS standard (o businesskey) • Tramite credenziali Active Directory Per interrogare l’Attribute Authority (AA) l’applicazione deve inoltrare una Attribute Query all’interno di un SOAP Message all’indirizzo del webservice della AA. L’AA restituisce una SAMLresponse contenente un’asserzione di attributo (un’asserzione contenente un’Attribute Statement). Se l’applicazione si occupa di gestire informazioni sugli utenti che possono essere certificate come attributi, l’applicazione stessa può diventare un’Attribute Authority. loginfvg mette a disposizione delle applicazioni un componente web che dialoga con l’applicazione tramite un webservice standard e che espone gli attributi certificati dall’applicazione nella modalità richiesta dalle AA SAML (Attribute Authority Esterna Non SAML). Tali AA Esterne possono essere contattate direttamente oppure possono essere federate con loginfvg, in modo tale che, quando qualcuno richiede l’attributo in questione, sia loginfvg a recuperarlo dalla AA Esterna e inserirlo tra gli attributi dell’utente. Il portafoglio delle asserzioni di un utente è un costrutto XML denominato SAMLResponse. Per interrogare le due Authority di loginfvg è quindi necessario l’invio di una richiesta SAML firmata e codificata in Base64, nello specifico una AuthenticationRequest per l’IdP e una AttributeQuery per l’AA. In entrambi i casi la risposta sarà una SAMLResponse contenente le asserzioni firmate, rilasciate dalle rispettive Authority, inviata tramite una request HTTP di tipo POST, in formato codificato Base64. Analizziamo ora il primo caso, ossia come interrogare le Authority inviando richieste SAML. Pag. 8 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 9 di 16 28 marzo 2014 Le caratteristiche che deve avere la <AuthnRequest> sono le seguenti: • deve essere presente l’attributo ID univoco; • deve essere presente l’attributo Version; • deve essere presente l’attributo IssueInstant a indicare l’istante di emissione della richiesta, in formato UTC; • deve essere presente l’attributo ProtocolBinding, una URI reference che identifica il binding da utilizzare per inoltrare il messaggio di risposta (<Response>): deve valere sempre “HTTP-POST”; • deve essere presente l’attributo Destination, a indicare l’indirizzo (URI reference) a cui è stata inviata la richiesta, cioè il servizio SSO Service del Local Proxy; • deve essere presente l’attributo IsPassive con valore “false”, poiché non si vuole prevenire l’interazione esplicita tra certificatore di identità e utente; • deve essere presente l’attributo AssertionConsumerServiceURL a indicare l’URL a cui inviare il messaggio di risposta alla richiesta di autenticazione (in questo caso l’indirizzo del servizio ACS del Service Provider); • deve essere presente l’elemento <Issuer> a indicare l’entità emittente (il Service Provider o altro soggetto riconosciuto nell’ambito della federazione); • l’elemento <NameIDPolicy> e il relativo attributo AllowCreate devono segnalare all’Identity Provider tramite il Local Proxy che non è ammesso che l’identificativo dell’utente venga creato contestualmente alla fase di autenticazione (in altre parole, si richiede che il subject sia già registrato presso il certificatore d’identità); • l’attributo ForceAuthn deve valere “false” (per consentire all’Identity Provider di riutilizzare un contesto di autenticazione precedentemente creato per l’utente in precedenza, nell’ambito della stessa sessione di lavoro (Single-Sign-On); • l’attributo ProxyCount dell’elemento <Scoping> deve correttamente indicare il numero di redirezioni permesse verso i certificatori di identità: nel caso in esame deve valere almeno “2” per consentire l’attraversamento di Local Proxy e Profile Authority per poter infine giungere su un Identity Provider; • l’attributo AttributeConsumingServiceIndex deve essere posto pari all’indice posizionale della struttura AttributeConsumingService presente nei metadati del Service Provider e atta a descrivere i requisiti in termini di attributi necessari da parte del servizio offerto dal Service Provider e richiesto dall’utente; • l’elemento <RequesterID> dell’elemento <Scoping>, se presente, deve indicare l’entityID del Service Provider; • deve essere presente l’elemento <RequestedAuthnContext> a indicare il contesto di autenticazione atteso (per esempio la “forza” delle credenziali richieste); • Nel caso venga usato il binding HTTP-POST, deve essere presente l’elemento <Signature> apposto dal Service Provider, contenente la firma dell’intero messaggio. Di seguito un esempio di AuthRequest per l’IdP: Pag. 9 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 10 di 16 28 marzo 2014 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceIndex="0" AssertionConsumerServiceURL="url dell'applicazione chiamante" ForceAuthn="true" ID="A3814B1C5EBDB7D48A75F90C2A274C941338367294499" IssueInstant="2012-05-30T10:41:34.000Z" ProviderName="http://172.22.15.24:10080/ws3/IdpAuthnRequest" Version="1.2"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://fvgaccount.insiel.it:10080/ws3/MetadataPublisherServlet?meta=IDPmetadata</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:Reference URI="#s231e3a715714745c318cc7ae3525785e87f80bc5b" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ec:InclusiveNamespaces PrefixList="ds saml samlp" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">DDijrDdCcgGUly1vSUb9VPfrx5o=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> jyEgVPWXKdTqLVwmQU35QNwDg9HIkDAHKlZG8pjDo9tBQ62GwdWftd2RsO2gHDt0Qh7ZaiVMyt+H El8kdSY5SWOGRYQ7mcn+MSEBK0fr24Kw9SZLqSnndhy1PF1M0HV7AgeWGq/+ucsROwqb2aUI7hdX jxPJLwQQN+CoU0Z6yPE= </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>[CERTIFICATO X509 CODIFICATO IN BASE64]</ds:X509Certificate> <ds:X509Certificate>[CERTIFICATO X509 CODIFICATO IN BASE64]</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml:Conditions xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NotBefore="2012-05-30T10:41:34.000Z" NotOnOrAfter="2012-0530T11:11:34.000Z"/> <samlp:RequestedAuthnContext> <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> Pag. 10 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 11 di 16 28 marzo 2014 <samlp:Scoping> <samlp:RequesterID>http://fvgaccount.insiel.it:10080/ws3/IdpAuthnRequest</samlp:RequesterID> </samlp:Scoping> </samlp:AuthnRequest> In questo caso l’AuthenticationRequest va inviata attraverso una request http di tipo POST all’url del componente di Authority; l’indirizzo di callback va messo nell’attributo AssertionConsumerServiceURL mentre le varie modalità di autenticazione da rendere disponibile all’utente vanno indicate nel tag samlp:RequestedAuthnContext. samlp:RequestedAuthnContext. Request di tipo POST indirizzata a IdpAuthRequest: <form name="formLogin" method="POST" action=”URL web IdP”> <input type="hidden" name="SAMLRequest" value=”AuthRequest firmata e codificata in Base64”> </form> Forniamo ora un esempio di AttributeQuery per interrogare il webservice della Attribute Authority. Gli scenari di interazione per la richiesta di attributi da parte del Service Provider si basano sul “SAML SOAP binding” previsto dalla specifica OASIS. Questo binding prevede che i costrutti SAML di richiesta e risposta siano inclusi nel body dei messaggi SOAP scambiati (al massimo una richiesta o una risposta per messaggio). Il binding prescrive inoltre l’uso di “SOAP over HTTP”, che prevede l’uso di un header SOAPAction come parte di una richiesta SOAP. Pag. 11 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 12 di 16 28 marzo 2014 Costrutti SAML trasportati con binding SOAP over HTTP o HTTPS I costrutti SAML a cui si fa riferimento sono <AttributeQuery> e la relativa <Response>. Le caratteristiche che deve avere in questo caso la <AttributeQuery> sono le seguenti: • deve essere presente l’attributo ID univoco; • deve essere presente l’attributo Version; • deve essere presente l’attributo IssueInstant a indicare l’istante di emissione della richiesta, in formato UTC; • deve essere presente l’attributo Destination, a indicare l’indirizzo (URI reference) a cui è stata inviata la richiesta, cioè il servizio Attribute Service del Local Proxy; • deve essere presente l’elemento <Issuer> a indicare l’entità emittente (il Service Provider); allo scopo di poter specificare qual è il servizio richiesto al Service Provider, relativamente al quale si sta facendo una richiesta di attributi del profilo utente, data la mancanza di opportune strutture all’interno della AttributeQuery e volendo evitare di estendere la specifica, il valore dell’elemento <Issuer> dovrà essere ottenuto concatenando all’Issuer stesso il carattere “#” e l’indice del servizio richiesto dall’utente al Service Provider. • deve essere presente l’elemento <Subject> a indicare l’utente a cui si riferisce la richiesta di attributi; • possono essere presenti uno o più elementi <Attribute>, il cui Name indica l’attributo di cui si vuole conoscere il valore e deve essere specificato sia il Name che il FrendlyName, conformememente a quanto specificato negli Accordi di Servizio del Circle of Trust; • deve essere presente l’elemento <Signature> apposto dal Service Provider o altra autority rioconosciuta all’interno della federazione. Pag. 12 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 13 di 16 28 marzo 2014 <samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="FC327A44C501A9754CF5FB2E742D03C81338375883033" IssueInstant="2012-05-30T13:04:43.000Z" Version="2.0"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameidformat:transient">FVGaccountAttributeAuthority</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:Reference URI="#s201d4f2679ae7ea6349c7236f82c5ae423e05af9e" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-excc14n#" PrefixList="ds saml samlp"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">LBVYfg7rUIbnS/ZOKX5rmJ8GnUw=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> pu+36efIeK9u5TsZJdT2JMPK2DH95DCDnxJ/m6VnZ3hi7qzZoI+Cc3546k1s1WUZmCLupSEnNqN2 ImLSOPsElMZoNN/+Zc4w/43xdo4CnctuNnl3zYkGUp0p6pFO8reOymIQLQULTv/OYnpDVChfFsl9 O26gXGG0U8hGgWaZdaw= </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>[CERTIFICATO X509 CODIFICATO IN BASE64]</ds:X509Certificate> <ds:X509Certificate>[CERTIFICATO X509 CODIFICATO IN BASE64]</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">Codice Univoco Utente (Codice Fiscale)</saml:NameID> </saml:Subject> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Attributo 1" Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> Pag. 13 di 16 Divisione Integrazione e Architetture - Area Architetture loginfvg Specifiche tecniche IDIA--ARC ARC--000 000640 640--SPT SPT--14 14--0004 IDIA 640 Pag. 14 di 16 28 marzo 2014 <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Attributo 2" Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.27" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Attributo 3" Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.28" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> </samlp:AttributeQuery> L’Attribute Query va messa nel body di un SOAP Message da inviare al webservice dell’Attribute Attribute Authority, Authority che risponde con una SAMLResponse contenente un’Asserzione di Attributo. Elementi chiave della richiesta sono, oltre agli attributi, di cui occorre specificare il nome e il Friendly Name, la chiave univoca dell’utente del quale vengono richiesti gli attributi, nel nostro caso, e come normato da DigitPA, il Codice Fiscale. 2.3. Utilizzo dei Metadata Un’entità (IDP, AA, SP, LP etc.) è descrivibile tramite documenti XML con un formato definito dallo standard SAML 2.0 nel documento relativo ai metadati. Tramite i metadati è possibile definire il tipo di un’entità, le sue chiavi pubbliche, proprietà utili (come la richiesta di firma dei costrutti forniti o richiesti) e d è possibile definire i servizi, ed in particolare il loro indirizzo URL e il tipo di binding supportato. Tutte le entità proprie dell’ambito di loginfvg sono dotate di un proprio documento di metadati secondo lo standard SAML 2.0 il quale è firmato dalla Regione FVG in qualità di Fiduciario, a sancire l’affidabilità delle informazioni specificate nei metadati stessi. Pag. 14 di 16
© Copyright 2024 Paperzz
