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.
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.
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
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
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?
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.
> 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..
Steps 2 and 3 are unrelated to the gallery. The gallery entry is basically a registered url that takes you to the app, to trigger a login (2) which triggers provisioning (3) in your tenant. So you can visit any app and add it to your tenant by signing into the app. Lots of folks want a gallery entry though, so that's what the docs focus on
>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.
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.
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?!