22. 11. 2024
Atlassian, Service Management
Starting with the Windows Server 2003 R2 version, Microsoft introduced the Active Directory Federation Services (ADFS), a software component which provides users with single sign-on access to systems and applications located across organizational boundaries.
ADFS is part of the Active Directory Services.
The authenticated user is provided with a series of Claims related to his / her identity that are inserted into a Token, which is digitally signed (a SAML Token). This token is then recognized and used by the various applications that accept this authentication scheme which enables Single Sign On mode for an application.
The advantage is that the user authenticates once on the ADFS service and then does not need to provide his/her credentials again to the various application servers that may also be outside the network containing the Active Directory Domain.
Architecture scheme
Usually the ADFS architecture uses two, possibly redundant, servers: one that connects directly with the Active Directory Domain, and is then located within the corporate network, and a proxy that is not part of the domain and is normally placed in the DMZ and exposed on the Internet through the HTTPS port.
Optionally, the internal ADFS server may coincide with the Active Directory Domain Controller server.
In the figure below, all the blue highlighted streams are HTTPS connections.
The internal user connects directly with the internal ADFS server. In this case, if you are using a Windows client, it can also perform an automated authentication via Kerberos.
The external user is redirected to the Proxy ADFS server and must explicitly authenticate on a Portal.
In both cases, the user is eventually provided with a Token SAML that can be used by those applications that accept Claims.
Access to a Claim Application with SAML Token Authentication
The user who accesses a Claim application is normally redirected to the Identity Provider service. Only after he has obtained a SAML Token, may he return to the application with valid credentials.
The process follows the following phases:
where the Service Provider is the application that requires a Claim authentication and the Identity Provider is in our case the Microsoft ADFS.
Example of a Shibboleth integration
Microsoft ADFS generates the Token Claim and it must be adapted to the application: the Claim attributes expected to identify and authorize the user must be generated.
From this point of view, the ADFS servers are very flexible because they allow each web application to define the mode in which the SAML Token is built.
One of the most common cases is the integration with a web application that uses the Shibboleth framework: it is an open security standard licensed under Apache 2 and based on the Security Assertion Markup Language (SAML) infrastructure. ADFS assumes the role of Identity Provider (IdP) by providing information about the user, while the Application assumes the role of the Service Provider (SP) using the information to give access to protected content.
Shibboleth can then be used as a framework to provide users with a single sign on Web applications such as Erizone or Neteye.
On the ADFS side, Shibboleth configures a Relying Party Trust for each web application: creating Claim Rules that define which claims are generated and, where applicable, how they should be processed from the data in the Active Directory.
For example, if Shibboleth wants to provide the User Principal Name (UPN) as a Claim in the generated Token, the Issuance Transform Rules must be specified before reading the User-Principal-Name from Active Directory and putting it in the Standard Windows Account Name Claim.
A second custom rule, executed shortly afterwards, transforms the Claim Windows Account Name into a Claim recognized by 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”);
In the end, the Token SAML will contain a Claim defined as follows:
urn:oid:1.3.6.1.4.1.5923.1.1.1.6
that is able to be read and used by the Shibboleth Framework.
In the same way, you may be able to read the Active Directory samAccountName attribute and provide it to Shibboleth if the web application intends to use this attribute to identify the user.
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
25. 07. 2024
Asset Management, NetEye
GLPI Device Discovery
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