04. 02. 2020
NetEye, Service Management
A partire dalla versione Windows Server 2003 R2, Microsoft ha introdotto il servizio ADFS (Active Directory Federation Services) come lo strumento di gestione del controllo di accesso e di autorizzazione di tipo Claim. ADFS si appoggia ad un dominio Active Directory.
All’utente che viene autenticato vengono forniti una serie di Claim relativi alla sua identità e questi vengono inseriti in un Token firmato digitalmente (SAML Token), Token che viene poi riconosciuto ed utilizzato dalle varie applicazioni che accettano questo schema di autenticazione, fornendo di fatto all’utente una modalità di Single Sign On applicativo.
Il vantaggio è che l’utente si autentica una volta sola sul servizio ADFS e non deve fornire le sue credenziali ai vari server applicativi che potrebbero essere anche esterni alla rete che contiene il Dominio Active Directory.
Schema dell’architettura
Normalmente l’architettura ADFS utilizza due server, eventualmente ridondabili: uno che dialoga direttamente con il Dominio Active Directory e quindi si trova all’interno della rete aziendale ed un Proxy che non fa parte del dominio e normalmente viene posizionato in DMZ ed esposto in Internet attraverso la porta HTTPS.
Eventualmente il server ADFS interno può coincidere con il server Domain Controller dell’Active Directory.
Tutti i flussi di dialogo evidenziati in azzurro in figura sono HTTPS.
In pratica l’utente Interno dialoga direttamente con il server ADFS Interno: in questo caso se utilizza un client Windows può anche effettuare con esso un’autenticazione automatica via Kerberos.
L’utente esterno viene rediretto verso il server ADFS Proxy e qui necessariamente deve effettuare un’autenticazione esplicita su un Portale.
In entrambi i casi all’utente viene alla fine fornito un Token SAML che può essere utilizzato verso l’applicazione in grado di accettare i Claim.
Fasi di accesso ad un’Applicazione di tipo Claim con autenticazione tramite Token SAML
L’utente che deve accedere ad un’Applicazione di tipo Claim viene normalmente rediretto verso il servizio di Identity Provider: solo dopo che ha ottenuto un Token SAML, può ritornare a presentarsi all’applicazione presentando così delle credenziali valide.
Il processo si svolge attraverso queste fasi:
dove il Service Provider è l’applicazione che richiede l’autenticazione di tipo Claim e l’Identity Provider è nel nostro caso il servizio Microsoft ADFS.
Esempio di integrazione con Shibboleth
Il Token Claim che viene generato dal servizio Microsoft ADFS deve essere adattato all’applicazione: devono essere generati gli attributi Claim che quest’ultima si aspetta per identificare ed autorizzare correttamente l’utente.
Da questo punto di vista ADFS è molto flessibile perché consente per ogni applicazione web di definire la modalità nella quale viene costruito il Token SAML.
Uno dei casi più diffusi è quello di integrazione con un’Applicazione web che utilizza il framework Shibboleth: si tratta di un’infrastruttura basata sullo standard aperto Security Assertion Markup Language (SAML). ADFS assume il ruolo di Identity Provider (IdP) fornendo le informazioni sull’utente, mentre l’Applicazione quello di Service Provider (SP) utilizzando le informazioni e dando accesso ai contenuti protetti.
Shibboleth è open source ed è rilasciato con licenza Apache 2.
Shibboleth può quindi essere utilizzato come framework per fornire agli utenti un Single Sign On su Applicazioni web tipo Erizone o Neteye.
Lato Microsoft ADFS viene configurato un Relying Party Trust per ciascuna Applicazione web: all’interno delle Claim Rules che definiscono quali Claim vengono generati ed eventualmente come devono essere trasformati a partire dai dati presenti in Active Directory.
Nel caso di Shibboleth ad esempio volendo fornire lo User Principal name (UPN) come Claim nel Token generato, nelle Issuance Transform Rules va specificato prima di leggere da Active Directory lo User-Principal-Name e di metterlo nel Claim standard Windows Account Name.
Una seconda regola di tipo Custom, eseguita subito dopo, trasforma il Claim Windows Account Name in un Claim riconosciuto da Shibboleth:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/
windowsaccountname”]
=> issue(Type = “urn:oid:1.3.6.1.4.1.5923.1.1.1.6”, Value = c.Value, Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/
claimproperties/attributename”] = “urn:oasis:names:tc:SAML:2.0:attrname-format:uri”);
Di fatto alla fine il Token SAML conterrà un Claim definito come
urn:oid:1.3.6.1.4.1.5923.1.1.1.6
in grado di essere letto ed utilizzato dal Framework Shibboleth.
In modo analogo può essere eventualmente letto l’attributo samAccountName di Active Directory e fornito a Shibboleth, nel caso in cui l’Applicazione web intenda utilizzare questo attributo per identificare l’utente.
Alessandro Romboli
Site Reliability Engineer at Würth Phoenix
My name is Alessandro and I joined Würth-Phoenix early in 2013. I have over 20 years of experience in the IT sector: For a long time I've worked for a big Italian bank in a very complex environment, managing the software provisioning for all the branch offices. Then I've worked as a system administrator for an international IT provider supporting several big companies in their infrastructures, providing high availability solutions and disaster recovery implementations. I've joined the VMware virtual infrastructure in early stage, since version 2: it was one of the first productive Server Farms in Italy. I always like to study and compare different technologies: I work with Linux, MAC OSX, Windows and VMWare. Since I joined Würth Phoenix, I could also expand my experience on Firewalls, Storage Area Networks, Local Area Networks, designing and implementing complete solutions for our customers. Primarily, I'm a system administrator and solution designer, certified as VMware VCP6 DCV, Microsoft MCP for Windows Server, Hyper-V and System Center Virtual Machine Manager, SQL Server, SharePoint. Besides computers, I also like photography, sport and trekking in the mountains.
Author
Latest posts by Alessandro Romboli
11. 04. 2024
Business Service Monitoring, NetEye, SLM
SLA Reporting on a Business Process
06. 12. 2023
Business Service Monitoring, NetEye
Monitoring a Business Process
07. 08. 2023
Business Service Monitoring, ITOA, NetEye
From Icinga 2 Monitoring to ITOA
07. 12. 2022
Business Service Monitoring, NetEye, Unified Monitoring
Monitoring Veeam Backup & Replication