ComeRilasciareAttributiShibv4
Indice
Quali attributi SAML vengono trattati all'interno della Federazione IDEM?
Gli attributi selezionati in IDEM provengono dall'insieme degli attributi di base definiti per il protocollo LDAPv3 [RFC4519] e dagli schemi Cosine, inetOrgPerson, eduPerson [EDUPER] e Schac [SCHAC].
Gli attributi possono descrivere diversi tipi di caratteristiche dell’utente e si dividono in tre categorie principali:
Caratteristiche personali (P): Ad esempio il nome, il cognome e il titolo dell’utente.
Contatti (C): Attributi utilizzati per contattare personalmente l’utente al fine di fornirgli il servizio o parte di esso mediante strumenti diversi dal web.
Autorizzazioni e Accounting (A): Attributi sull’affiliazione, il ruolo dell’utente nella propria organizzazione, identificativi personali persistenti, attributi di sottoscrizione del servizio o autorizzazioni aggiuntive.
Per ottenere l'elenco completo degli attributi visualizzare la seguente tabella:
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.propertiesalla voceidp.attribute.resolver.LDAP.exportAttributes - la si compila sulla base di cosa è presente in AD/Ldap
- opzione
- Attribute Definition - tag xml
<AttributeDefinition ... >
Attribute Registry - tutto il contenuto della cartella conf/attributes/
Premessa
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 seguendo 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: link file.
Questo rappresenta un'ottima base di partenza a cui aggiungere le ulteriori definizioni Attribute Definition tenendo a mente le seguenti strategie:
- se uno degli attributi che si vuole rilasciare è recuperabile da uno dei Data Connector già definiti nel file
attribute-resolver.xmled ha un nome standard che Attribute Registry sa codificare allora basterà inserire il nome di tale attributo nel fileldap.propertiesalla rigaidp.attribute.resolver.LDAP.exportAttributese 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
- se uno degli attributi che si vuole rilasciare è recuperabile da uno dei Data Connector già definiti nel file
attribute-resolver.xmle non ha un nome standard allora oltre ad inserire il nome di tale attributo nel fileldap.propertiesalla rigaidp.attribute.resolver.LDAP.exportAttributessarà 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>
- se uno degli attributi che si vuole rilasciare NON è recuperabile da un Data Connector già definito nel file
attribute-resolver.xmlma 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 diattribute-resolver.xml) allora oltre ad inserire il nome dell'attributo sorgente nel fileldap.propertiesalla rigaidp.attribute.resolver.LDAP.exportAttributessarà 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
