@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:
https://github.com/discourse/discourse/commit/3d76ce14219a168bdf85769c5474420951c14253
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가 활성화된 상태에서 메일링 리스트를 포럼으로 가져올 때 정말 유용한 방법입니다.
(스레드 부활을 해서 죄송합니다 
– 2년이 지났는데도 질문이 아직 열려 있는 것 같고, 이 조언을 다른 곳에서 찾을 수 없었습니다)
SSO와 함께 일반적인 사용자 초대 기능이 작동하면 한 단계로 처리할 수 있을 것 같아 좋겠습니다. (그리고 현재는 관리자만 2단계를 수행할 수 있는 것으로 보이지만, модератор도 수행할 수 있게 되면 좋겠습니다.)
@RyanK / @tobiaseigen 이 이슈를 닫아도 좋을 것 같습니다. 이제 초대 기능이 SSO와 완벽하게 호환되어야 합니다. 지난 2년간 많은 진전을 이루었으므로, 여러분의 사용 사례를 네이티브로 처리할 수 있어야 합니다.
네, 종료해도 될 것 같습니다. 실제로 SSO 또는 사이트가 제공하는 기타 로그인 방법을 통해 로그인하도록 사람들을 초대하는 것은 매우 가능합니다. 초대의 설정 방식에 따라, 초대된 사용자는 로그인할 때 특정 그룹에 추가되고 특정 토픽으로 이동될 수 있습니다. 꽤 훌륭하네요! 
여기서 논의되는 대부분의 내용은 실제로 SSO를 통한 사용자 그룹 추가 및 제거 지원에 관한 것이며, 이 부분은 제가 잘 알고 있지 않고 메타 포럼에서도 관련 문서를 많이 찾아볼 수 없습니다. 이 부분에 대해 더 잘 아는 분이 이를 정리하여 FAQ를 작성해 주시면 좋겠습니다. 이 기능은 사용자가 SSO로 로그인할 때 그룹에 추가되거나 제거되도록 허용하는 것으로, 실제로는 초대 시스템과는 무관합니다.
@simon 님이 WordPress를 사용하여 이를 수행하는 방법에 대한 좋은 예시를 보여 주셨습니다: Automatically Adding New Users (from WP integration) To A Group - #4 by simon
다만 몇 가지 주의할 점이 있어, 이 방법을 구현하도록 장려하는 것이 가치가 없을 수도 있습니다. 이 기능이 작동하려면 Discourse 그룹이 이미 존재해야 하며, 인증 제공자 측에서 변경 사항이 반영되려면 사용자가 로그아웃을 한 뒤 다시 로그인해야 합니다.