Azure AD SAML federation using Shibboleth SP

7 min readNov 9, 2020

Recently, I was trying to figure out how can I federate with Azure AD using Shibboleth SP and achieve SSO. There are applications that do not have a built-in SAML, OAuth or OIDC module, using which it can federate with Azure AD. Shibboleth SP provides this capability to such legacy applications to federate with Azure AD using SAML authentication mechanism. I had no idea how Shibboleth works and I was struggleing a lot to meet my goal. I almost went through all available documents on the web, but could not find any reference document for this scenario.

I reached out to Twitter and Microsoft Q&A for community help, but still waiting for a positive response. Sounds like I am the first one in world who is trying achieve this! 😎

So, I decided to try this out myself as I was confident that technically this should be a supported configuration.

Concept

SAML is an authentication mechanism that allows an Identity Provider (IDP) to securely pass authentication and authorisation data to a Service Provider (SP). In my case, Azure AD is the IDP and Shibboleth is the SP.

I am going to describe, how I made this concept work with Shibboleth SP.

Configure IDP

Let’s start with configuring the IDP, this is the easier half of the setup!

Login to Azure portal and go to Azure Active Directory
Under Manage section click on Enterprise applications
Click on +New application, then search for SAML
Select SAML 1.1 Token enabled LOB App
You can rename it as per your wish. I renamed it to shibboleth-demo.
Now click on Create to create the AAD Enterprise application.
Once the Enterprise application is created, go into the application. Add the users to Users and groups, to whom you want to grant the SSO access to the target application. I have added my account here.
Now, go to Single sign-on under Manage section of the Enterprise application and click on SAML.
Copy Azure AD Identifier and keep with you; this will be something like: https://sts.windows.net/341aad7c-768b-4b4b-9362-xxxxxxxxxxxxxx/
We will come back here later to finish up the configuration

Configure SP

I am going to host the SP on an Azure Vitual Machine (VM). I created a Red Hat Enterprise Linux 7.6 VM on Azure and used Standard B2s (2 vcpus, 4 GiB memory) VM size. I have inbound port 443 (HTTPS) allowed on my NSG.

Install Apache Web Server

Now, I will install Apache Web Server and configure to run it over HTTPS with a self-signed certificate. Note that, I am logged on to the server as root.

Run the following commands to install and start Apache Web Server service (httpd).

#yum install httpd
#systemctl enable httpd
#systemctl start httpd

Install mod_ssl and restart httpd service. mod_ssl is an optional module for Apache Web Server. It provides strong cryptography for the Apache Web Server.

#yum install httpd mod_ssl
#systemctl restart httpd

Now, create a self-signed certificate by running the following command.

#openssl req -newkey rsa:2048 -nodes -keyout /etc/pki/tls/private/shibboleth-demo.key -x509 -days 365 -out /etc/pki/tls/certs/shibboleth-demo.crt

Update Apache SSL configuration with the self-signed certificate. Open the followig file with an editor of your choice.

#vim /etc/httpd/conf.d/ssl.conf

Search for the followig section and update certificate and key file paths used during self-signed certificate creation.

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/shibboleth-demo.crt#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/shibboleth-demo.key

Create an OS firewall rule to allow inbound port 443 by runnig the following commands. This may or may not be required depending on the firewall configuration of the OS of your VM.

#firewall-cmd --permanent --zone=public --add-port=443/tcp
#firewall-cmd --reload

At this stage you can access https://<Apache web server’s ip address> and it will give the following default page.

Install Shibboleth SP

Now, I am going install the latest supported version of Shibboleth SP on the VM by running the following commands and run it as a service.

#wget https://download.opensuse.org/repositories/security://shibboleth/CentOS_7/security:shibboleth.repo -P /etc/yum.repos.d
#yum install shibboleth
#systemctl enable shibd
#systemctl start shibd

Verify Shibboleth installation by runnig the shibd -t command. The last line confirms that the installation is successful.

#shibd -t 
2020-11-09 10:47:08 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
2020-11-09 10:47:08 WARN Shibboleth.Application : insecure cookieProps setting, set to "https" for SSL/TLS-only usage
2020-11-09 10:47:08 WARN Shibboleth.Application : handlerSSL should be enabled for SSL/TLS-enabled web sites
2020-11-09 10:47:08 WARN Shibboleth.Application : no MetadataProvider available, configure at least one for standard SSO usage
overall configuration is loadable, check console or log for non-fatal problems

Configure Shibboleth SP

The Shibboleth SP configuration is primary done by updatig shibboleth2.xml file under /etc/shibboleth directoy.

Go to /etc/shibboleth and take a backup of shibboleth2.xml file.

#cd /etc/shibboleth
#cp shibboleth2.xml shibboleth2.xml.backup

Now, open shibboleth2.xml file with an editor of your choice. Modify the below mentioned sections of the file as specified below in bold.

Under ApplicationDefaults update the entityID with a unique value as mentioned below.

<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
    <ApplicationDefaults entityID="https://<DNS name of the application or Apache web server's ip>/shibboleth"
        REMOTE_USER="eppn subject-id pairwise-id persistent-id"
        cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">

Update the following section of the file as mentioed below (in bold).

<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
checkAddress="false" handlerSSL="true" cookieProps="https" redirectLimit="exact">

Under SSO section, update entityID value with the Azure AD Identifier URL that we copied while configuring the IDP. Then comment out the line under it.

<SSO entityID=”https://sts.windows.net/341aad7c-768b-4b4b-9362-xxxxxxxx/">
 <!-- discoveryProtocol=”SAMLDS” discoveryURL=”https://ds.example.org/DS/WAYF"> -->
 SAML2
 </SSO>

Un-comment the following section in bold. This is the section for IDP metadat, we will setup this later.

<!-- Example of locally maintained metadata. --><MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>

Save and close the file and restart shibd and httpd services.

At this stage you should get the following response, if you browse the below mentioned URL.

https://<Apache web server's ip>/Shibboleth.sso/SessionA valid session was not found.

Generate SP Metadata

The Shibboleth SP is now configured and ready to generate the SP metadata. The metadata can be generated in the followig two ways:

Access the below mentioned URL from a browser. This will generate and download the SP metadata. Inspect and edit the metadata generated this way before uploading into IDP. Let’s rename the file sp-metadata.xml

https://Apache web server's ip>/Shibboleth.sso/Metadata

I prefer this method as it doesn’t require any edit after generating the metadata. Run the following command by modifying the fields in bold to generate the metadata in sp-metadata.xml file under /etc/shibboleth.

#cd /etc/shibboleth
#./metagen.sh -c sp-signing-cert.pem -h <DNS name of the application or Apache web server's ip> -o <"Your organisation name"> -u <"URL"> > sp-metadata.xml

Finishing up IDP Configuration

Upload SP metadata

Go to the Enterprise application (shibboleth-demo) that we created durig IDP configuration.
Click Single sign-on under Manage section of the Enterprise application and click on SAML.
Upload the SP metadata file (sp-metadata.xml)
Put the following URL in Sign on URL field (if required). All other fields will get auto populated by the XML import

https://<DNS name of the application or Apache your web server's ip>/Shibboleth.sso/Login

Save Basic SAML Configuration page and close the application

Download IDP Metadata

Go to the Enterprise application (shibboleth-demo)
Go to Single sign-on under Manage and download Federation Metadata XML (IDP metadata) from SAML Signing Certificate section. Rename the file as partner-metadata.xml

Finishing up SP Configuration

Copy partner-metadata.xml to /etc/shibboleth and restart shibd service. I uploaded the file to the Linux VM using FileZilla.

At this stage we have both IDP and SP configured. Now, we have to protect Apache Web Server by Shibboleth.

Shibbolethise Apache Web Server

Go to the following path and open shib.conf file by using an editor of your choice.

#cd /etc/httpd/conf.d
#vim shib.conf

Update the file as follows, if you want to protect a specific application folder

<Location /<FolderName>>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>

Update the file as follows, if you want to protect the root directory of the Web Server

<Location />
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>

Save and close the file. The restart httpd and shibd service. In my case, I am going to protect the root directory.

Verify SAML/SSO

At this stage, I have SAML federation configured for the root Apache Web Server.

Now, if I access https://<Apache web server ip>, I get redirected to the Microsoft Login page.

On successful authentication, I get the following Apache web page.

This proves the federation concept works. However, at the moment I do not have an application that has a login page.

Next step is to setup a web application with a login page and see how the claims or attribute mappings are working.

Thanks for reading, give it a 👏 if you like it. Please leave a comment and let me know if you have any feedback.