SAML Authentication with Microsoft Active Directory

[Nils Nilsson]

Hello.

My organisation is attempting to configure SAML with our Microsoft Active Directory.
We find that the documentation is lacking for this usecase and, even taking inspiration from the pages for AzureAD(EntraID) and PingID, could not produce a working integration.

Primarily I haven't found any documentation that specify the callback urls for logon/logout.

Thanks you for your advice,
Nils Nilsson

[dan.brown_0128]

Have you found a solution to disabling users in Proget when their access has been removed, or updating their groups when updated on the backend (without needing re-login to the web app)? We're running into challenges with keeping API Key access in sync with the user's actual access since Proget's internal user database doesn't synchronize against our identity backend.

[rhessinger]

Hi @Nils-Nilsson,

In order to use SAML with Active Directory, you will need to make sure your SAML claims are returning a Subject's NameID that matches the samAccountName in Active Directory excluding the domain suffix. Then if it finds that username in Active Directory, it will use it's permissions. If it does not find it, it will then create a user in the Built-In User Directory.

The Subject's NameID is a bit confusing because it looks like each service uses a different term for this. For example, EntraID's (Azure AD) SAML claims name it nameidentifier. Really it is whatever claim value is set in the SAML envelope under saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID.

As for the callback URL; it is specified in the configuration wizard when setting up EntraID (Azure AD) and PingID, but not for other SAML providers. It also looks like this got removed from our documentation page, which I'll add back now. The callback URL should be https://«PROGET_HOST»/saml-acs-callback .

@dan-brown_0128,

The best way to handle this is to use the expiration feature on API keys or using a separate script (PowerShell, Shell, etc...) in a Scheduled Task or CRON Job to check your SAML or AD provider for access and then use our API to disable API keys. Although I have never set this up, I know many SAML providers offer Webhook subscriptions for when access is removed. That could be another option for disabling API keys in ProGet.

Thanks,
Rich

[Nils Nilsson]

Hi @rhessinger

Thanks for rectifying the missing callback URL.
Unfortunately it made no difference for our case as that was already the URL we were using.

We made sure to verify that NameID is being sent in the claim without domain prefix.
All other settings in our ADFS configuration looks as we would expect for a normal SAML integration.

Currently any attempt att signing in using Single Sign-On returns this error: "ERROR: Object reference not set to an instance of an object."

Regards,
Nils

[rhessinger]

Hi @Nils-Nilsson,

At this point, I would suggest using our debug endpoint to see what the SAML response sent to us is and how we interpret it. You can do that by change the callback URL in your SAML provider to https://«PROGET_HOST»/saml-acs-callback-debug then attempt to login to ProGet using your SAML provider. You will then be redirected to a debug page that shows you the SAML details. That should be able to help you identify what is missing. If you need help, you can email us the contents of that page to support@inedo.com with a subject of [QA-2681] SAML and then reply to this letting us know you sent it.

Thanks,
Rich

[Nils Nilsson]

Hi @rhessinger

Thanks for telling me about the debug endpoint, would have been nice if debug options was made visible in the documentation, since there is already a header for troubleshooting -> https://docs.inedo.com/docs/installation/saml-authentication/various-saml-overview#troubleshooting.

Using the debug output we managed to figure out our issue and get it working.
In our case NameID was being sent as an attribute instead of being part of the subject, resolving that fixed our issue.

<AttributeStatement>
  <Attribute Name="NameID">
      <AttributeValue>User ID</AttributeValue>
  </Attribute>
</AttributeStatement>

changed to

<Subject>
  <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">User ID</NameID>
</Subject>

Other information omitted for privacy.

Thank you for your assistance in resolving this.
Regards
Nils

[rhessinger]

Hi @Nils-Nilsson,

Glad to hear it's working for you! Also, thanks for the feedback on adding that to our docs, I'll work on getting that added soon.

Thanks,
Rich