Azure AD SAML Integration issue with PingFederate : AADSTS75011

Readers, I'm back!

I would like to resume blogging my working experiences and best possible solutions on technologies that I come across every day.

Today, I would like to share some limitation that I came across on Azure AD SAML integration.

Scenario:

A cloud application is integrated with PingFederate where Ping is IDP and app is SP.
PingFederate is delegating authentication to Azure AD; so Ping is SP and Azure AD is IDP.

Issue:
As per the scenario, all three systems Application, PingFederate and Azure AD are configured with SAML integration.

When Application is accessed, it is throwing an error when it is landing on Azure AD for authentication.

Cause:
As per Azure error code AADSTS75011, the problem seems to be Authentication Context parameter sent by the Application in SAML Authentication request as shown below.

<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>

Refer this article, https://techcommunity.microsoft.com/t5/azure-active-directory/aadsts75011-by-which-the-user-authenticated-with-the-service/m-p/196130#

Azure AD supports only urn:oasis:names:tc:SAML:2.0:ac:classes:Password as authentication context value in SAML requests. Refer this article, https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol

Fix:
Ensure that application would send AuthnContextClassRef parameter as urn:oasis:names:tc:SAML:2.0:ac:classes:Password

Enabling Multi factor Options for application in Okta

Okta is a simple product to use and it is capable of integrating with more than 5800 applications for Single Sign-On purposes with added security benefits.

In this post I would like to quickly talk about enabling Multi Factor capabilities for an application that is already integrated into Okta. In this case, SalesForce is integrated with Okta using SAML 2.0 protocol.

Follow the below steps to enable MFA capabilities for salesforce application (or this would apply for any other application)

1. Login to Okta Admin Console as admin user.
2. Goto Applications.
3. Goto Sign On Policy section.
   
4. Click Add Rule.
5. Specify Rule Name, Conditions (users /group rule assignment), Location . 
   
6. Specify Actions. Select the option to allow or deny the access after conditions are met. For this exercise I would choose Allow. Select MFA frequency such as prompting MFA every login or once a day etc.,
7. Click on Multifactor Settings.
   
8. Select the desired authenticators. 
   
9. Click Save. 

Now the desired configuration changes are completed. It is time to test. 

1. Login to Okta application console. 
2. Click on SalesForce application.
   
3. User is redirected to MFA page for setup (if its already setup, this page is not seen). In this case, I have selected Google Authenticator setup. Click Setup.
   
4. Select device Type. Install app on mobile device. Click Next.
   
5. Specify the code generated on mobile device here. Click Verify.
   
6. User is redirected to salesforce application. 
   

Recommendations while using custom federation

Suppose you are the Service Provider using COTS federation product and your partner is Identity Provider using custom federation solution. Here are some personal recommendations for achieving SAML Single Sign-On in a smooth manner.

1. Identify the features you are implementing with your partner upfront such as HTTP Binding, Signing, encryption, logout, Query Attributes, Account Linking etc., 
2. Discuss and agree the certificate, private key, encryption algorithms etc., 
3. Setup local environment to do proof of concept with COTS products and make sure you implement all the agreed features.
4. Make sure your partner having custom federation solution has done POC so that you are sure that they are adhering to SAML standards. 
5. If your partner has not done any POC in their local environment then you will need to validate the metadata manually before importing it to Service Provider.
6. When partner metadata is validated and make sure it is imported in your Service Provider properly. Be heedful of syntactical errors. 
7. If your partner has SAML response tested by dummy client, then ask for SAML response. If the response is encoded, use a SAML decoder and verify if all the elements are present. This is where we ended up wasting lot of time while running the test and identifying each and every element missing in SAML response. 
8. It is always suggested to test the basic federation without Signing/Encryption/Attribute Query etc.,
9. Once basic federation is tested, signing is next step.
10. Then test the encryption.

SAML2 encoder/decoder

Hi All,

I was working on Fedlet setup with OIF 11g. I could not get to see SAML assertions in Fedlet debug logs, I don't know why. The goal is to look at the SAML request and response for nameid and other details.

So here is the simple way to get saml xml's. One should be able to see the SAMLRequest and SAMLResponse in http headers while testing the federation URLs in browser.

Use the tool https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php and paste the SAMLRequest encoded data and click the Decode SAML Message.
Another one here, http://openidtest.uninett.no/samldebug 
The same holds true for both SAMLRequest and SAMLResponse data.