The SAML Authentication Plugin page here indicates that “SAML Authentication is available on Enterprise hosting plans.”
Does this mean that I would be unable to use SAML Authentication on my self hosted free version of Discourse? Ideally, I’d want to use Azure AD authentication for my Discourse instance.
That message is in reference to our hosting. It means you cannot use the SAML plugin on our standard or business tier.
That said, you shouldn’t need SAML for Azure-AD. See OpenID Connect Authentication Plugin for a much simpler setup. There are Azure-AD specific notes at the end.
So all plugins listed in the Plugin Directory can be used on my self-hosted free discourse instance?
Absolutely! And there are far more #official plugins than listed on the website you’re free to use. Be sure to also check out #theme-component.
Thanks again for the added information.
So the goal is that my internal users use Azure AD for authentication/registration and that external users can register via a local account, or other account registration plugins. This is why SAML was my first thought.
Would I be able to limit the OpenID Connect Authentication plugin with Azure AD and limit it to just internal users?
OpenID Connect, as well as SAML, are “authentication providers”. By configuring one on your site, users, by default, will be able to choose between local login or an auth provider. Meta is a good example, you have the choice of local login, Facebook, Google, GitHub, etc.
In your case, users would have the choice between local and OpenID, or local and SAML. You can choose whichever you prefer and is easier to configure for your setup.
You can do this with either plugin, as who can log in would be handled by Azure AD, not the plugin you use to connect to Azure.
Would it be possible to hide it from external users though? I wouldn’t want our customers to try and think they would be able to login using Azure AD.
What about a separate login/registration page that would only be known to internal users where Azure AD authentication is the only option?
You can hide the login link via CSS, then no users can see it. You could then share (or publish on an internal site) a direct link to the OpenID or SAML login for your internal users. As the users aren’t logged in when they hit the login page, there’s no way to know if their internal or not.
You can also change the button label to try and avoid confusion. For example, in the image below we labeled the button for “internal users” Discourse Staff. If not Discourse Staff try to use it, so be it:
Joshua - I truly appreciate your prompt and informational assistance.
Thanks a bunch and stay safe!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
