What security risks may be involved with others knowing the sso secret?
My WordPress install is multisite and multiuser. There doesn’t seem to be a way to set Discourse settings at the network level from the WP plugin. This doesn’t seem to be a huge problem otherwise (though it would smooth workflow), but I can’t find a way to prevent the subsite admins from having access to the plugin settings, which include the sso secret.
Discourse is using the network level user table as the endpoint so that the Discourse users are basically an aggregate of all sites. I’d rather not provide access or security holes for subsite admins to see the full network user list/details. All of the subsite admins do not have admin/moderator privileges in Discourse. In effect, my Discourse admin privileges are more like Super Admin privileges in Wordpress multi-site, and the lack of plugin settings at the network level blurs this line.
Have I simply failed to discover the plugin’s network level settings? If not, is anyone working on improving Wordpress multisite compatibility?
I was going to say “if you know that the secret is compromised, cycle it and move on”; but that doesn’t seem to apply here. Uh, I think the fix is to lock down who can see the plugin settings. Where would that be done? I’m not a WP expert.
Unfortunately, the point of the subdomain admins having access is that they need access to other site-specific plugins. That makes isolating a single plugin difficult, and really, that’s the purpose of the Super Admin level. The clean solution would be to move that setting to the Network level of the WordPress Discourse plugin. Alas, my ability to alter the plugin currently hovers around zero.
What are the risks with the sso secret being available to the subsite admins? If all it does is open the possibility for them to see the network/Discourse user list, it might be okay. If it opens the door to them logging in to accounts or gaining Super Admin privileges, I’d have to choose another route.
The immediate idea that popped into my mind is to have the WordPress plugin see who is currently viewing the plugin settings. If any user credentials don’t match the admin(s) of the attached Discourse forum, then the plugin settings are greyed out or the page won’t load and will throw a 403.
Thanks, @purldator. That’s an interesting workaround. I have no idea how to implement it, but I see what you’re getting at and it makes sense.
@riking, That’s what I was afraid of. Thank you for explaining why the secret needs to stay a secret. It’s very helpful to know the risks.
This is beyond the scope of WordPress, but would another potential route be to add a user level sso secret in Discourse–something like to the user API key?
As it relates to WordPress, the cleanest way would be to add better Network Plugin support. There are a few other settings that make sense to manage network-wide, so perhaps someone with more dev skills than I runs into similar issues.
Elusive obvious in the short term: SSO isn’t necessary for the sub-sites if all auth is routed through the main network site endpoint. So… drum roll… leave the sso secret field blank in the sub-sites’ plugins settings. Problem solved.
Well I’m off to try to invent more ultra-complex solutions to non-existent problems. Oy.