@sam What do you think about this idea? Is it something that’s likely to be added?
We just started our community and are rolling out to a number of different audiences in stages. The first audience is general and doesn’t need to be added to any groups, but our next audience will be a specific group that should get special treatment.
Allowing groups to be specified via SSO is fine, my pref would be for 2 keys
groups: [group1,group2,group3]
remove_groups: [remove1]
That should allow you full fidelity here, should be fairly straightforward to add. We can slot it for 1.7
Glad to hear this is something you can support.
The only issue I see with having a remove_groups flag is that I will need to know what groups the user is no longer a member of to remove them. What about supporting three keys:
groups: [group1,group2,group3] # ensure user is only in groups1, group2, and group3
or
add_groups: [group4] # ensure user is in group4
remove_groups: [group2] # ensure user is not in group2
This way, my main app can handle all the logic and Discourse will simply be kept in sync.
I think the only way that works is the second one, because otherwise the membership of any group you create through the Discourse UI will have its members removed as they re-log.
The remove groups parameter would then be managed_group_list - user.groups (inventing the terminology of a “sso-managed group” for the sake of this post).
We can revisit that design if the managed groups list gets too big.
That’s the desired behavior for me. I don’t want people managing user groups in the discourse admin. I want our main app to have full control of group memberships.
This is now completed per:
Sorry to re-open this, but I’m trying to make sure I understand what was (or wasn’t) done to solve the use cases presented earlier.
I’m also on SSO. With a Discourse hosted site. We want to have a private forum where we can invite people select people, but unfortunately it’s not tied to a parameter we can identify and pass via SSO.
We want to upload a list of email addresses that, if/when a user signs in for the first time they are auto-added to the group. We are using the domain solution for some groups, but that wouldn’t apply in this case.
It looks like this was discussed, but it’s unclear to me which solution was ultimately chosen. I tested with an email address that was registered in our main userbase, but hadn’t logged into our discourse site to initiate the SSO. When we logged in with that ID the account created but he’s not in the group.
这是我找到的基于电子邮件地址列表将 SSO 用户预先添加到群组的方法：
email_time_window_minutes 时间内删除该私信）当启用 SSO 时，这对于将邮件列表导入论坛非常有用。
（抱歉对旧帖进行“复活” 
– 看来这个问题两年后仍未解决，我在其他地方找不到此建议）
如果正常的“邀请用户”功能能够与 SSO 配合使用，那就更好了，这样可以在一步内完成操作（并且让版主也能执行此操作，目前看来只有管理员可以执行步骤 2）。
@RyanK / @tobiaseigen 我很确定这可以关闭了，现在的邀请应该与 SSO 高度兼容，我们在过去两年里取得了巨大进展，应该能够原生支持你的用例。
是的，我认为我们可以结束了。确实可以邀请用户，然后他们可以通过 SSO 或网站提供的任何登录方式登录。根据邀请的设置方式，被邀请的用户可以在登录时被添加到组中并放入特定主题。非常棒！
这里的大部分讨论实际上是关于SSO 支持用户添加到组和从组中移除，我对这方面不太熟悉，并且在这里的 meta 上没有找到太多相关文档。更熟悉的人可以写一篇 FAQ 来汇总关于它的已知信息。它允许用户在通过 SSO 登录时被添加到组或从组中移除，这实际上与邀请系统无关。
这是 @simon 使用 WordPress 的一个很好的例子：Automatically Adding New Users (from WP integration) To A Group - #4 by simon
但是，有一些注意事项，所以也许不值得鼓励人们实施这种方法。Discourse 组必须已经存在才能使其工作，并且它要求用户注销并重新登录才能使身份验证提供商端的任何更改生效。