ComeRilasciareAttributiShibv4

Quali attributi SAML vengono trattati all'interno della Federazione IDEM?

Leggere il documento: File:Specifiche Tecniche V1.2 20120612.pdf

Elementi chiave della configurazione Shibboleth v4

Attribute Resolver - file conf/attribute-resolver.xml

• Data Connector - tag xml <DataConnector ... >
  • opzione exportAttributes è il puntatore alla lista degli attributi da recuperare dal Data Connector
  • la lista effettiva è definita nel file ldap.properties alla voce idp.attribute.resolver.LDAP.exportAttributes
  • la si compila sulla base di cosa è presente in AD/Ldap
• Attribute Definition - tag xml <AttributeDefinition ... >

Attribute Registry - tutto il contenuto della cartella conf/attributes/

La risoluzione degli attributi

La risoluzione degli attributi (Attribute Resolver - https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631549/AttributeResolverConfiguration) è il processo di raccolta dei dati relativi ad un determinato soggetto dopo che questo si è autenticato nell'Identity Provider.

Il servizio Resolver non contiene direttamente i dati ma le istruzioni per recuperarli dalle varie fonti dei dati (Data Connectors - https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631564/DataConnectorConfiguration) e tramite la definizione degli attributi (Attribute Definition - https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631550/AttributeDefinitionConfiguration) è possibile configurare il modo in cui i dati vengono usati, combinati e trasformati. I dati utente recuperati da questo processo sono salvati all'interno di oggetti chiamati IdPAttribute.

Nelle versioni precedenti dell'IdP Shibboleth, il servizio resolver era anche responsabile del collegamento dei cosiddetti AttributeEncoders agli oggetti da utilizzare successivamente per produrre l'Encoding specifico del protocollo SAML.

Questo è ancora supportato, ma un approccio migliore in V4 consiste nell'affidarsi a un insieme comune di regole di codifica contenute nella nuova AttributeRegistryConfiguration e basate su convenzioni ragionevoli per i nomi degli oggetti IdPAttribute. Ad esempio, se si accetta semplicemente di inserire l'indirizzo e-mail del soggetto in un IdPAttribute chiamato "mail", il registro sa come codificarlo in SAML automaticamente utilizzando il nome prescritto dallo standard [https://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile]

Per impostazione predefinita il servizio di risoluzione degli attributi si trova nel file attribute-resolver.xml  In esso sono definiti gli attributi da risolvere. È possibile specificare ed utilizzare più file "resolver" modificando il bean a cui fa riferimento la proprietà idp.service.attribute.resolver.resources(valore predefinito  shibboleth.AttributeResolverResourcesnel  file services.xml  ) o modificando la proprietà con un nome di bean diverso.

Attribute Registry

Il servizio Attribute Registry è una nuova aggiunta alla V4 che fornisce un modo più avanzato per configurare la relazione tra gli oggetti interni IdPAttribute che sono (per la maggior parte) prodotti da Attribute Resolver e il modo in cui i dati sono rappresentati nei protocolli supportati da il software come SAML, CAS o in futuro OIDC.

L'Attribute Registry è stato progettato per affrontare la mappatura dei dati tra formati indipendentemente dall'Attribute Resolver, il quale si occupa principalmente di come ottenere i dati e non di come codificarli.

Lo scopo di questo nuovo servizio Attribute Registry è supportare casi d'uso aggiuntivi che non erano, se non del tutto, supportati dal vecchio design, come ad esempio:

• proxy di attributi ottenuti da provider SSO esterni che non provengono da Attribute Resolver
• mappatura di SAML (o altri protocolli) in dati interni, come nel caso di  <RequestedAttribute>elementi nei metadati SAML
• eliminare la necessità della definizione di attributi di tipo SimpleAttributeDefinition se utilizzato esclusivamente per collegare gli Attribute Encoders.

Per approfondimenti:

https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1272054306/AttributeRegistryConfiguration

Risoluzione degli attributi in Shibboleth IdP v4 con le guide di IDEM

Se avete installato un IdP v4 seguendo le guide del servizio IDEM allora state sfruttando tutte le potenzialità del servizio Attribute Registry.

Questo significa che per definire un attributo non è più necessario, nella maggior parte dei casi, collegare alcun Attribute Encoder.

Al contrario, copiare nella v4 una definizione di attributo che funzionava nella versione v3 potrebbe produrre la duplicazione del valore di quell'attributo.

... esempio ...

Inoltre, uno dei grandi vantaggi apportati da Attribute Registry è quello di eliminare la necessità di definire un attributo se questo ha un nome standard ed è recuperato, senza necessità di ulteriori trasformazioni, da un Data Connector in cui l'attributo stesso è stato definito nell'opzione exportAttributes.

Per conoscere quali attributi sono esportabili da AD/Ldap è sufficiente usare il comando ldapsearch

Esempio: rilasciare l'attributo "mail" ricavato dal Data Connector "myLdap"

... esempio ...

Tramite la guida di installazione Idp vi è stato fornito un file attribute-resolver.xml di esempio: attribute-resolver-v4-idem-sample.xml.

Questo rappresenta un'ottima base di partenza a cui aggiungere le ulteriori definizioni Attribute Definition tenendo a mente le seguenti strategie:

Attributo recuperabile as-is in AD/LDAP

se uno degli attributi che si vuole rilasciare è recuperabile da uno dei Data Connector già definiti nel file attribute-resolver.xml ed ha un nome standard che Attribute Registry sa codificare allora basterà inserire il nome di tale attributo nel file ldap.properties alla riga idp.attribute.resolver.LDAP.exportAttributes e questo sarà recuperato e codificato in SAML senza alcuna ulteriore definizione

# file conf/ldap.properties
idp.attribute.resolver.LDAP.exportAttributes = uid givenName sn cn displayName mobile title preferredLanguage telephoneNumber eduPersonAffiliation eduPersonEntitlement eduPersonOrgDN eduPersonOrgUnitDN eduPersonOrcid schacMotherTongue schacPersonalTitle schacUserPresenceID schacPersonalUniqueID schacPersonalPositon schacPersonalUniqueCode matricolaStudente

In questo esempio sono stati esportati i nomi degli attributi come definiti all'interno di Openldap e dato che molti di essi hanno dei nomi standard, non c'è bisogno di definirli in attribute-resolver.xml

Attributo recuperabile in AD/LDAP rinominando l'attributo sorgente

se uno degli attributi che si vuole rilasciare è recuperabile da uno dei Data Connector già definiti nel file attribute-resolver.xml e non ha un nome standard allora oltre ad inserire il nome di tale attributo nel file ldap.properties alla riga idp.attribute.resolver.LDAP.exportAttributes sarà necessario creare una AttributeDefinition per rimappare il nome non standard in uno standard (senza definizione di Encoder perché ci penserà AttributeRegistry)

# file conf/ldap.properties
idp.attribute.resolver.LDAP.exportAttributes = uid givenName sn cn displayName mobile title preferredLanguage telephoneNumber eduPersonAffiliation eduPersonEntitlement eduPersonOrgDN eduPersonOrgUnitDN eduPersonOrcid schacMotherTongue schacPersonalTitle schacUserPresenceID schacPersonalUniqueID schacPersonalPositon schacPersonalUniqueCode matricolaStudente

<!-- file attribute-resolver.xml -->
<AttributeDefinition xsi:type="Simple" id="mail">
   <InputDataConnector ref="myLDAP" attributeNames="e-Mail" />
</AttributeDefinition>

Attributo non presente in AD/LDAP ma generato da un attributo sorgente tramite combinazione o trasformazione

se uno degli attributi che si vuole rilasciare NON è recuperabile da un Data Connector già definito nel file attribute-resolver.xml ma può essere ottenuto per combinazione o trasformazione di altri attributi sorgente (recuperati a loro volta da un Data Connector o già definiti in una Attribute Definition di attribute-resolver.xml) allora oltre ad inserire il nome dell'attributo sorgente nel file ldap.properties alla riga idp.attribute.resolver.LDAP.exportAttributes sarà necessario creare una Attribute Definition per definire come l'attributo viene ottenuto (senza definizione di Encoder perché ci penserà AttributeRegistry)

# file conf/ldap.properties
idp.attribute.resolver.LDAP.exportAttributes = uid givenName sn cn displayName mobile title preferredLanguage telephoneNumber eduPersonAffiliation eduPersonEntitlement eduPersonOrgDN eduPersonOrgUnitDN eduPersonOrcid schacMotherTongue schacPersonalTitle schacUserPresenceID schacPersonalUniqueID schacPersonalPositon schacPersonalUniqueCode matricolaStudente

<!-- file attribute-resolver.xml -->
<AttributeDefinition id="schacPersonalUniqueCode" xsi:type="Template">
 <InputDataConnector ref="myLDAP" attributeNames="matricolaStudente"/>
 <Template>urn:schac:personalUniqueCode:int:esi:%{idp.scope}:${matricolaStudente}</Template> </AttributeDefinition>

L'esempio definisce l'attributo "schacPersonalUniqueCode" a partire dall'attributo sorgente "matricolaStudente" che è presente in Ldap e che viene estratto/esportato dal Data Connector grazie alla riga idp.attribute.resolver.LDAP.exportAttributes del file ldap.properties

Attributo per il quale non sono definiti gli Encorders in Registry

...