Take the advantage of Okta Passwordless experience to access all your ADFS integrated applications.
In this article we are Integrating Okta as IDP with ADFS as SP where Salesforce has been SAML integrated with ADFS.
Prerequisites:
- Active Directory running 2008 R2 or higher.
- ADFS installed and configured. (ADFS doesn’t need to be exposed to the internet if only using on premise or through VPN)
- Okta Tenant (https://www.okta.com/free-trial/)
- Okta integration with AD (https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-get-started.htm)
- Create a few users in AD to by synced and active with Okta
- Salesforce integrated with ADFS. https://help.salesforce.com/s/articleView?id=sf.identity_provider_examples_3p_adfs.htm&type=5
1.) Create a SAML Integration Application in Okta console.
On the Okta Admin dashboard got to –> Applications –> Applications –> Create App Integration –> SAML 2.0 –> Ok.
The Attribute statement in our case is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
Tips to find the Audience URI: On your ADFS server open a browser and past the URL: https://”yourAdfsFqdn”/FederationMetadata/2007-06/FederationMetadata.xml
Open the downloaded XML and locate the Entity ID:
Back to our Okta App creation click next and finish.
It is now time to Assign your application to the user or group user you may want to provide access to ADFS’s Integrated Applications
Last step in Okta consist to download the Okta IDP Metadata. See below screenshot download the Metadata file as XML and copy it over to your ADFS Server.
2.) Setting up Okta as an IDP Into ADFS
On you ADFS server, locate and open the ADFS Management console. Click on Claims Provider Trusts and then Add Claims Provider Trust. Click start to begin the process.
Leave everyhting after by default and finish the wizard to the end.
– We can configure in a way that we Pass Through to ADFS (SP) all the incoming claim including the UPN which will require to modify each app (Relaying Party) on ADFS with a transformation Rule to pass the UPN to a Name ID so SSO can be handled. (This is the step we will follow in this article for testing purpose)
-Second one is to trick AD with a Change Issuer at the Claim Provider level by adding a custom Claim rule so we do not need to touch any of the existing ADFS integrated Relaying Party Trusts (Applications)
Here the custom rule:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“, Issuer = “AD AUTHORITY”, OriginalIssuer = “AD AUTHORITY”, Value = c.Value, ValueType = c.ValueType);
In this Article we want to Pass Through to ADFS (SP) all the incoming claim including the UPN. Select Pass through and click next.
At this stage we now have Okta setup as IDP when a user wants to access ADFS. You can test it by entering the ADFS URL and select Okta IDP. The URL for me is: https://adfs.ebden.local/adfs/ls/idpinitiatedsignon.aspx
3.) Configure the Relying party Trusts to Pass the UPN as Name ID.
In this exemple we are configuring this way as it is required by salesforce to present into the SAML Asserstion the Name ID.
At this stage you are ready to Access your ADFS Applications, in this case Salesforce, leaving Okta as your main IDP. See below the awesome user experience using the latest Okta Fast Pass technology:
To improve the end user experience you can also configure the Microsoft ADFS Realm Page so the IDP Okta in this case will be automatically selected during the login process reducing the number of steps.
Here the Powershell command for this use case:
Set-AdfsRelyingPartyTrust -TargetName Salesforce -ClaimsProviderName @(“Okta IDP”)
Troubleshooting
Coming soon
Credits:
With the precious help of my super co workers Paul Devis, Dragan Vladicic and Dean Comben.
Dany Leclerc's Blog 
Leave a Reply