Invitations should be compatible with SSO

[codinghorror (Jeff Atwood)]

Don’t we already have this “if the user is in a certain email domain and their email is verified, add them to the X group” feature? I am pretty sure we do, it is an option in the groups edit dialog.

[sam (Sam Saffron)]

We have

But its not quite targeted enough (covers a domain, not an individual user’s email) and would be a nightmare to maintain this way.

[codinghorror (Jeff Atwood)]

Would it be simpler to support upload of a list of email addresses or usernames that need to be in a specific group? Say “these 50 random emails in this file, if matching existing accounts, need to be in the X group”.

Maybe if you could add email addresses to a group as well as usernames.

[sam (Sam Saffron)]

Sure, this could work, but we would need a new UI for this.

[Tom_Newsom]

This functionality would suit us very well, although polling an external file/db for those emails would be more flexible.

[adundovi (4ndY)]

I don’t really understand how this would work. Since the parent site has to create the account before it is handed to us, how exactly does an invitation URL work in that scenario? Can you describe how it would work, step by step starting with how the URL is formed in the email invite?

The motivation for this option is that there are some features missing in Discourse when SSO is enabled, most notably to invite someone by email (not only by username) at the end of the topic. In this scenario, when you enter an email to the invite field, Discourse will send an email to the invited person with a link to the external registration system (not to itself) combined with your username as a part of that url. After that SSO can pass to Discourse a field “invitedby” which will contain the same username.

But on second thought, there are too many parameters for it which are depending on an external system, so maybe it’s better not to implement it in Discourse itself, but in a plug-in.

[downey (Michael Downey)]

Can’t SSO specify Discourse group membership these days? If so I think the original idea is no longer relevant.

[sam (Sam Saffron)]

Nope. Only admin / moderator

[NiclasJ (Niclas Johansson)]

This would be great. I’m just in the process of activating a new, only-visible-to-group, category on our forum, and the rest of the forum is largely irrelevant to the target group here. (So it’s suboptimal to tell them first to go sign up on the forum, because it will give them the “wrong” idea initially of what the forum is about - but that’s the necessary workflow right now)
Is this a planned feature?

[techAPJ (Arpit Jalan)]

Would it be simpler to support upload of a list of email addresses or usernames that need to be in a specific group?

We now have this feature!

Bulk add to Group

Here’s a new feature some people might find userful: You can now bulk add people by email address or username to a group. Simply go to Groups > Bulk Add to Group in the admin section: [image] This is useful in the case where you have many existing users who need to be added to a new group. Remember: if you are adding new users to the site, our invite feature allows you to import a group at that time. If the users don’t exist that is the preferable route to take.

[johndbritton (John Britton)]

Are there any plans to support specifying groups via SSO?

[sam (Sam Saffron)]

Sure I totally support adding that. Semantics are a bit tricky though … something like:

groups:a,b,c

The tricky thing semantically is how to “remove” users from the groups if you sync SSO?

Perhaps couple an optional setting of “sso_allowed_groups” that lists the groups that are “settable” via sso. Then when you specify groups we can also ensure you are not mistakenly in any other sso_allowed_groups

[johndbritton (John Britton)]

Maybe better to list out the SSO group memberships in the sign in payload like this:

...
"group_memberships":
  {
    "group_a": true,
    "group_b": false
  }
...

That way listed memberships are updated, but unlisted memberships are not touched.

[Jared_Needell]

So I’ll share with you guys what I am doing.

I have OKTA setup as my SSO provider for authentication. OKTA connects to my company’s active directory environment and so I decided to use PowerShell to make scheduled tasks pre-staging users, placing them into groups, and also making them watchers of categories based on what group they are in.

I’ll share with you some of the PowerShell Snippets I have

Here are some Utility functions
http://pastebin.com/fzipEepL

Here is what I use for pre-staging users, the utility script gets called to this.
http://pastebin.com/jF5nm9Xw

If the user already exists, Discourse won’t create another one. I might utilize my pgSQL connection to check if the user exists before calling the user creation.

And here is my group sync with AD groups
http://pastebin.com/nJFGrttW

Probably not the most efficient script but it works well.

Finally, I have a Discourse plugin that runs every 24 hours to make sure users remain watching a category even if they change it back to normal.

jaredneedell/discourse-watch-category-mcneel/blob/master/plugin.rb

[mcwumbly (Dave McClure)]

I have OKTA setup as my SSO provider for authentication

Are you using OKTA for SSO w/ Discourse too? What was involved in getting that set up?

[Jared_Needell]

Yeah, we had pay for professional services to set it up

[johndbritton (John Britton)]

@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.

[sam (Sam Saffron)]

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

[johndbritton (John Britton)]

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.

[riking (Kane York)]

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.