Recupero attributi da IdP

SPID
1

Buongiorno,
mi chiamo Antonio e sono uno sviluppatore java. Ho cominciato a muovere i primi passi nell’integrazione di una web app con SPID. Sto provando la configurazione tramite Apache+Shibboleth.

Ho installato e configurato, con diverse difficoltà a dire il vero (la documentazione, a mio parere, presuppone già una conoscenza abbastanza “spinta” di Shibboleth, SAML e dei concetti di integrazione tra SP & IdP in genere), i sistemi IdP di test (spid-testenv-identityserver) e di Shibboleth SP + backoffice su due macchine diverse (apache+shibbolet su una, idp sull’altra, cambiando hostname dell’idp ovviamente) e l’autenticazione avviene correttamente, ma ho un piccolo problemino relativo agli attributi.

Mi spiego. Il fatto è che nella configurazione SSO dell’SP, che la versione del vostro backoffice nodejs (almeno la versione che ho scaricato da github) crea su WSO2, NON è spuntato ‘Include Attributes in the Response Always’ (sotto “Enable Attribute Profile”) e, per tale ragione, NON mi vengono inviati - nemmeno all’atto della login - gli attributi che io richiedo con l’elemento md:AttributeConsumingService. Se, invece, pongo manualmente la spunta su ‘Include Attributes in the Response Always’ e salvo la configurazione, riesco ad ottenere le informazioni sull’utente log-ato.

Preciso che verifico la presenza degli attributi tramite l’handler /Session di Shibboleth.sso e una mini pagina php direttamente su Apache (cerco di capire come far funzionare il tutto prima di prevedere il proxypass su Tomcat).

Volevo chiedere quale fosse la configurazione nel vostro sistema di produzione e, qualora gli attributi non siano restituiti con le risposte, in che modo potrei recuperarli?

Perdonate le mie domande banali e/o da ignorante …

Grazie mille,
Antonio

1 Mi Piace
2

Ciao @tonyweb,

grazie per aver scritto! Intanto puoi intanto linkare i repository che hai utilizzato in modo che sia più semplice per chi legge entrare nel tema?

Per il resto, probabilmente @umbros ne sa qualcosa.

A presto!
R.

3

Grazie @Roberto_Polli per la risposta.

Ecco i repo che ho utilizzato:



Ho dovuto adattare un po’ alcuni script perchè avevo a disposizione delle macchine virtuali windows (e i repo sono pensati per macchine linux).

Grazie,
Antonio

4

Cosa un po’ strana, per me.

Se imposto in shibbolet2.xml l’indice a 1 per AttributeConsumingServiceIndex (quel che capisco è per “match-arlo” a quello indicato in WSO2, specificato tramite il metadata generato e caricato dal sistema backoffice)

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
	xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id..." Version="2.0" IssueInstant="2017-01-01T00:00:00Z" 
    AttributeConsumingServiceIndex="1" 
	ForceAuthn="true">

e aggiungo i mapping anche per il format basic (in attribute-map.xml):

	<!-- SPID - Basic (non so perche', però, sia necessario leggerli come basic quando sono transient) -->
    <Attribute name="spidCode" id="SPIDCODE" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>		
    <Attribute name="name" id="NAME" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />	
    <Attribute name="familyName" id="FAMILYNAME" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
    <Attribute name="placeOfBirth" id="PLACEOFBIRTH" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="countyOfBirth" id="COUNTYOFBIRTH" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="dateOfBirth" id="DATEOFBIRTH" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="gender" id="GENDER" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="companyName" id="COMPANYNAME" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="registeredOffice" id="REGISTEREDOFFICE" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="fiscalNumber" id="FISCALNUMBER" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="ivaCode" id="IVACODE" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="idCard" id="IDCARD" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="mobilePhone" id="MOBILEPHONE" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="email" id="EMAIL" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="address" id="ADDRESS" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="expirationDate" id="EXPIRATIONDATE" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
    <Attribute name="digitalAddress" id="DIGITALADDRESS" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>

mi vengono inviati gli attributi anche senza spunta sul flag ‘Include Attributes in the Response Always’ .

Ora mi sorgono dei dubbi:

  1. Anche in produzione (quando esporrò il metadata definitivo) dovrò porre ‘AttributeConsumingServiceIndex’ ad 1? O dipende solo dall’indice che pongo per il tag md:AttributeConsumingService nel metadata che esporrò?

  2. Quando imposto il flag ‘Include Attributes in the Response Always’ chiedo all’IdP di inviarmi tutti gli attributi indipendentemente dalla mia richiesta, giusto? E’ per questo che li vedevo anche senza un indice pari ad 1 …

  3. Devo necessariamente mappare gli attributi col nameformat basic perchè sono così dichiarati nel metadata del SP generato e caricato dal backoffice nell’Idp?

    E dunque non ha alcun effetto, nel metadata dell’IdP generato dal backoffice (https://localhost:8080/#/infoidp), l’indicazione a transient? <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>

Ora provo ad andare avanti e configurare il ProxyPass da Apache verso Tomcat e, dopo, proverò a recuperare i dati dell’utente da codice java :slight_smile:

Grazie in anticipo per qualsiasi risposta,
Antonio