AD FS 2016 and InvalidNameIDPolicy using SAML Authentication to SailPoint IdentityNow


I recently had a seemingly simple task for a customer to setup a AD FS 2016 relying party trust for their SailPoint IdentityNow deployment. Sounds easy right?

In this scenario AD FS 2016 was to be the Identity Provider (IdP) and IdentityNow the Service Provider (SP). Our end-goal of the solution was to allow the customer’s users to authenticate via SAML into IdentityNow using their corporate AD DS email address and password. Great outcome from a user experience perspective and for corporate governance too!… [Keep reading] “AD FS 2016 and InvalidNameIDPolicy using SAML Authentication to SailPoint IdentityNow”

ADFS Metadata Conversion for Shibboleth

I recently blogged about the issues integrating Shibboleth Service Providers with ADFS. As an update to that blog one of Kloud’s super smart developers (Alexey Shcherbak) has re-written the FEMMA Python script in PowerShell, removing the need for Python and the LXML library! The ADFS2Fed converts ADFS metadata for consumption by a Shibboleth SP. Below is the output of Alexey’s labour, awesome work Alexey!

[code language=”PowerShell” gutter=”false”]
$idpUrl = "";
$scope = "";
$filename = ((Split-Path -parent $PSCommandPath) +"\federationmetadata.xml");

$xel = [System.Xml.Linq.XElement]::Load($filename);

$shibNS = New-Object System.Xml.Linq.XAttribute @(([System.Xml.Linq.XNamespace]::Xmlns + "shibmd"), "urn:mace:shibboleth:metadata:1.0");

$scopeContent = New-Object System.Xml.Linq.XElement @("{urn:mace:shibboleth:metadata:1.0}Scope", (New-Object System.Xml.Linq.XAttribute @("regexp","false")),$scope);
$scope = New-Object System.Xml.Linq.XElement @("{urn:oasis:names:tc:SAML:2.0:metadata}Extensions",$scopeContent);

$authN = New-Object System.Xml.Linq.XElement @("{urn:oasis:names:tc:SAML:2.0:metadata}SingleSignOnService", (New-Object System.Xml.Linq.XAttribute @("Binding","urn:mace:shibboleth:1.0:profiles:AuthnRequest")), (New-Object System.Xml.Linq.XAttribute @("Location", ($idpUrl+"/adfs/ls/"))) );
$firstSSO = [System.Linq.Enumerable]::First( $xel.Descendants("{urn:oasis:names:tc:SAML:2.0:metadata}SingleSignOnService"));

$xel.Elements("{}Signature")|%{ $_.Remove()};
$xel.Elements("{urn:oasis:names:tc:SAML:2.0:metadata}RoleDescriptor") | %{$_.Remove()};
$xel.Elements("{urn:oasis:names:tc:SAML:2.0:metadata}RoleDescriptor") | %{$_.Remove()};
$xel.Elements("{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor")| %{$_.Remove()};

$xel.Save(($filename+"ForShibboleth.xml"), [System.Xml.Linq.SaveOptions]::None)

Shibboleth Service Provider Integration with ADFS

If you’ve ever attempted to integrate a Shibboleth Service Provider (Relying Party) application with ADFS, you’d have quickly realised that Shibboleth and ADFS are quite different beasts. This blog covers off some of the key issues involved and provides details on how to get ADFS to play nice with a Shibby Service Provider (SP). This blog does not cover configuring ADFS to participate as a member in a Shibboleth Federation like InCommon or the Australian Access Federation (AAF).… [Keep reading] “Shibboleth Service Provider Integration with ADFS”