# 인증으로 그룹 멤버십 관리 **URL:** \ **Category:** Development\ **Created:** [1월 13, 2021, 6:50오전 UTC](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950 "2021-01-13T06:50:24Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\ **Post date:** [1월 13, 2021, 6:50오전 UTC](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950/1 "2021-01-13T06:50:24Z")
@david 이 논의는 > > > If possible I'd like us to keep any modification of group membership out of this… group plugin, and instead move it into this method of discourse core > > https://github.com/discourse/discourse/blob/422f395042ef7f32d528a2c11e8da619fdbd5641/lib/auth/result.rb#L71-L89 > > That way, we have a clean API which all plugins can use. > > The most difficult thing here is the data model. How do you decide which groups to add and remove the user from? And how does that affect manually adding/removing users from groups in Discourse itself? > > e.g. > 1. a user authenticates via OIDC with groups \`\['group1', 'group2'\]\` > 2. In the discourse UI, the user is added to \`group3\` > 3. later, the same user authenticates via OIDC with groups \`\['group1'\]\` > > Inspecting this as a human, we can see that the final state should be \`group1, group3\` (group2 should be removed). But I don't think there is enough state being tracked to make that decision programmatically. Similarly: > > 1. a user authenticates via OIDC with groups \`\['group1', 'group2'\]\` > 2. In the discourse UI, the user is removed from \`group1\` > 3. later, the same user authenticates via OIDC with groups \`\['group1', 'group2'\]\` > > Now what should happen? An admin has explicitely removed the user from \`group1\`, but OIDC just added them back. This is very confusing UX for the admin. We may need some way to identify groups as 'externally managed', and hide all the add/remove UI 🤔 > > If we can iron out the data model, then I think this would be a great addition to Discourse core. If you like, a topic on Discourse Meta would be welcome. Happy to help with implementation there once we plan things out. 에서 이어지는 것입니다. 추측하시겠지만, 저는 openid-connect 플러그인에 국한되지 않는 이 문제의 안정적인 해결책도 보고 싶습니다. 앞으로 나아갈 방법을 함께 찾아보겠습니다. 제가 언급한 점을 이어가 보겠습니다. > 사용자가 어떤 그룹에 추가되고 제거되는지 어떻게 결정하나요? 그리고 이것이 Discourse 자체에서 사용자를 그룹에 수동으로 추가/제거하는 데 어떤 영향을 미치나요? > > 1. 사용자가 `['group1', 'group2']` 그룹으로 OIDC 인증을 수행합니다. > 2. Discourse UI에서 사용자는 `group3`에 추가됩니다. > 3. 나중에, 같은 사용자가 `['group1']` 그룹으로 OIDC 인증을 수행합니다. > > 이를 사람이 검사해 보면, 최종 상태는 `group1, group3`(group2는 제거되어야 함)여야 한다는 것을 알 수 있습니다. 하지만 프로그래밍 방식으로 그 결정을 내릴 만큼 충분한 상태가 추적되고 있다고 생각하지 않습니다. 마찬가지로: > > 1. 사용자가 `['group1', 'group2']` 그룹으로 OIDC 인증을 수행합니다. > 2. Discourse UI에서 사용자는 `group1`에서 제거됩니다. > 3. 나중에, 같은 사용자가 `['group1', 'group2']` 그룹으로 OIDC 인증을 수행합니다. > > 이제 어떻게 되어야 하나요? 관리자가 명시적으로 사용자를 `group1`에서 제거했는데, OIDC가 다시 추가해 버렸습니다. 이는 관리자 입장에서 매우 혼란스러운 UX입니다. 그룹을 '외부 관리’로 식별하고 모든 추가/제거 UI를 숨기는 방법이 필요할 수도 있습니다 🤔 이 문제를 처리할 수 있는 몇 가지 방법이 있다고 생각합니다 (서로 배타적이지 않음) ### 그룹 및 토큰 속성 식별 어떤 구현 방식이든, 다음 사항을 명시적으로 식별해야 합니다. 1. 인증을 통해 멤버십을 관리할 수 있는 그룹은 어떤 것인지; 그리고 2. 인증 토큰 내에서 그룹 멤버십을 결정하는 속성은 어떤 것인지 이는 사이트 설정, 그룹 설정 또는 기타 방식으로 이루어져야 하며, 기본값은 "꺼짐"이어야 합니다. ### 엄격하거나 관대한 처리 그룹이 식별된 토큰 속성에 없으면 사용자가 제거되는 경우 처리 방식은 "엄격(strict)"합니다. 그룹이 식별된 토큰 속성에 없어도 사용자가 제거되지 않는 경우 처리 방식은 "관대한(permissive)"입니다. 엄격/관대한 상태는 그룹별로 설정됩니다. 사이트 설정에서 이를 수행하는 방법에 대한 예시는 여기 있습니다: [Conslidate group settings into group claim map - discourse/discourse-openid-connect@1665bdc - GitHub](https://github.com/discourse/discourse-openid-connect/pull/7/commits/1665bdccbb492788f64ba6844ad6f9ae1a41d95e). 동일한 접근 방식을 그룹 설정을 통해서도 수행할 수 있습니다. 제안하신 대로, 처리 방식이 "엄격"이라면 그룹 관리자를 통한 그룹 멤버십 추가/제거를 비활성화할 수 있습니다. ### 멤버십 출처 식별 또한 `group_users` 테이블에 그룹 멤버십의 출처를 저장하여 그룹 내에서 "혼합"된 접근 방식을 허용할 수도 있습니다. 즉, 관리자가 인증 토큰을 통해 생성된 멤버십을 제거할 수 없도록 하는 것입니다. 이 문제에 대해 더 생각할수록, 이는 그룹 설정을 통해 수행되어야 한다고 생각합니다. --- _[View the full topic](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950)._