[teknofobi]

Why does Microsoft seem to default to SAML for organisations using Azure AD?

All our enterprise customers on the Microsoft stack indicate SAML as the only viable option, whereas those on Google Workspace or on more custom IdAM setups in my experience don’t care if you as a vendor prefer SAML or OpenID Connect.

[hirsin]

The Enterprise Apps section is heavily SAML based, but if you want to look up how to write an app for AAD you won't likely find any SAML docs, you'll find the OIDC docs and oauth SDKs we build. If you see other places where you feel we default to SAML, I'd love to fix that.

[throwaway984393]

Probably the wrong person to ask, but it would be great if there were guides on replacing SAML with OIDC, if you're already using AzureAD. Our architects are so f'ing clueless they're still telling us to use SAML rather than OAuth2/OIDC to integrate our apps with AzureAD. But if there was an official guide, I could send an e-mail blast to a few higher-ups and say "SAML is teh suck, but here is MS's guide on upgrading to OIDC, it's easy, no more excuses plz kthx"

[hirsin]

Very much so the right person to ask! This is great to hear that there's a need for this. I think our mental model of a lot of enterprises is that "old code" stays SAML and new code (that isn't copy paste from old) is OIDC. If there's actual desire to migrate apps between the protocols, that's great. Can't promise easy though given the diversity of starting places. Thanks!

[throwaway984393]

Actually our tendency is to re-use the old solution on the new code if it provides the same functionality. We still have people trying to use LDAP because nobody wants to take the time to learn something new. A migration guide makes it much more likely that they'll make an attempt to use the new thing.

Our desire to upgrade pretty much only comes from Architects telling us "thou shalt follow my shiny new standard" (and by the way, they read your docs; if you suggest SAML be dropped, they'll update their standards!). In that case we have to find time to upgrade, and of course we never just document how to do it once for our whole org, so all these engineers will be wasting time re-learning how to do the same upgrade. I'll bet you we'd save hundreds to thousands of hours per year by having really good migration docs. Even if your migration guide doesn't cover everything, they still take a significant chunk out of the time we need to figure it all out, and it lowers the mental barrier to the change.

[merb]

where does it default to saml? btw. we use azure ad and only rely on openid connect.

[teknofobi]

It might just be cultural with the customers I’ve integrated with, but we’ve had a policy of requesting OIDC and then only doing SAML if that causes hiccups, and of a handful of SSO integrations with customers on the Microsoft stack there has always been hiccups. There might be other correlations here, such as the IT departments at Microsoft shops in our cases being more driven by consultants and managers.

[wtatum]

I've definitely seen this cultural bias towards SAML. I think it may be the case that a lot of enterprises have done a recent transition into Azure AD but have the same staff who had managed a legacy AD FS and have not adjusted with the times.

My approach has been to use Keycloak as an identity broker. It's implementation is quite robust and supports a lot of flexibility in terms of mapping custom assertions and the like. But the actual application "only speaks OIDC" and relies on access tokens to be reissued by Keycloak.

[user5994461]

ADFS on-premise support both since version 2016, some people are not aware of that. Azure support both.

The way it works in enterprise is that somebody wrote guidelines years ago that external software must support SSO with SAML. Then the guidelines were never updated and in some cases the company never realized they can support OIDC out of the box.

The exception is education, where Shibboleth is very entrenched with federations spanning all universities in some countries. Another exception for healthcare/defense that may not have updated any of their systems for 20 years, though they may not be customer if they have no internet connectivity and no SSO :D

[syshum]

Most likely they are talking about adding Non-Gallery Applications (Custom Applications) for SSO, the only option there is SAML

For OpenID Connect the developer has to sign up with Azure and have their app to the Gallery, you can not add a custom add yourself

Right now there are over 1100 Gallery apps using SAML, and only 500 using OpenID Connect

[hirsin]

This is inaccurate. Multi tenant apps can simply be signed into via OIDC and they're added to your tenant, if you allow it. All Microsoft apps use OIDC and are not allowed to use SAML, but SaaS app developers are not quite as far ahead.

But yes, we don't support dynamic registration of apps for eg OIDC/oauth

[tehbeard]

So no OIDC for "internal" apps?

I had thought I'd missed something when setting up some customers, and having to refactor to use SAML for SSO where we'd used OIDC for g-suite, but you're saying unless I throw it on the gallery (public app store?), It's only SAML?

[merb]

no. you register and you can either use saml or openid connect. btw. when you register your app you select if it is only for your tenant or for multiple tenants (or for microsoft accounts). your app never gets in the "public app store" unless you manually submit to. btw. this information is all public on their great docs.

[tehbeard]

> this information is all public on their great docs.

Public it may be, searchable it does not seem to be.

Every search seems to direct me towards [1] , Which is about gallery apps, and then directs me to a Table of contents entry that doesn't seem to exist (the closest I found was a tutorials page which is about connecting to a bunch of pre-existing SaaS apps, not for a "custom-developed app")

...maybe this is something where I have to burn half a week playing with Azure AD on a trial account to figure out..

[1] https://docs.microsoft.com/en-us/azure/active-directory/mana...

[syshum]

>yes, we don't support dynamic registration of apps for eg OIDC/oauth

Which is what I am talking about and ALOT of SaaS vendors do.

They have you go to AzureAD Go to Enterprise Applications, click "New Application" and then choose Application not found in Gallery.

When you do that, i can see no way to use anything other than SAML .

nothing in the Microsoft Docs, nor anything I can see on any portal gives the ability to for an Enterprise to Add their own Customer Open ID Connect application, you have to go through the process to add an App to the Gallery.

[hirsin]

Thanks for the feedback and experience! This is the difference between provisioning (adding an instance of an app to your tenant) and registration (Azure AD knowing your app exists). The pattern you're talking about is provisioning, and sadly yes, the manual route here is very focused on SAML. But anyone at all can register an app, and then anyone else can provision it into their tenant just by signing into it.

Will check out the docs and see what we can do, it's not good this was hard to learn.

[merb]

what are you talking? you can create openid connect applications in azure. and you need to sign up with azure one way or the other, saml 2.0 and openid connect applications actually need to have an app registration in azure which can only be created once your signed up?!

basically the app registration process for openid connect and saml is basically the same one?!

[syshum]

if I am in the AzureAD portal and go to Enterprise Applications, click "New Application" and then choose Application not found in Gallery.

When you do that, their are 3 SSO options for the new Applications, None of them are OpenID Connect

This is how 99% of all SaaS Vendors instruct people to add new Applications

[yrro]

You need to add an App Registration. The docs are pretty woeful!

[Serow225]

The naming does not help make things discoverable...

[aj3]

Well, it is de facto standard in Microsoft world. Honestly, I don’t actually share author's opinion, but it is well presented.