6 ms·

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 viab

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.

aj3 5y ago
Well, it is de facto standard in Microsoft world. Honestly, I don’t actually share author's opinion, but it is well presented.
merb 5y ago
where does it default to saml? btw. we use azure ad and only rely on openid connect.
- syshum 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        > 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/manage-apps/add-application-portal-setup-oidc-sso https://docs.microsoft.com/en-us/azure/active-directory/mana...
        merb 5y ago
        https://docs.microsoft.com/en-us/azure/active-directory/develop/ https://docs.microsoft.com/en-us/azure/active-directory/deve... this is the correct link if you want to develop something with the identity platform, the other link is more or less admin documentation...
        hirsin 5y ago
        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
    - syshum 5y ago
      >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 5y ago
        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 5y ago
    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 5y ago
      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 5y ago
        You need to add an App Registration. The docs are pretty woeful!
        Serow225 5y ago
        The naming does not help make things discoverable...
- teknofobi 5y ago
  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 5y ago
    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 5y ago
    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
hirsin 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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.

aj3 5y ago

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

merb 5y ago

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

syshum 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        > 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/manage-apps/add-application-portal-setup-oidc-sso https://docs.microsoft.com/en-us/azure/active-directory/mana...
        merb 5y ago
        https://docs.microsoft.com/en-us/azure/active-directory/develop/ https://docs.microsoft.com/en-us/azure/active-directory/deve... this is the correct link if you want to develop something with the identity platform, the other link is more or less admin documentation...
        hirsin 5y ago
        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
  - syshum 5y ago
    >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 5y ago
      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 5y ago
  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 5y ago
    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 5y ago
      You need to add an App Registration. The docs are pretty woeful!
      - Serow225 5y ago
        The naming does not help make things discoverable...
teknofobi 5y ago
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 5y ago
  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 5y ago
  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

hirsin 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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.