0

tldr: In building a platform where users can create private groups, and invite other people to those private groups, how is it be to secure those groups?

I'm building a platform around private groups and communities. I'm not really sure on what is the most suitable pattern/mechanism to secure groups so only those invited can read/write.

Technology is Okta and Spring Security.

Should I be creating groups and using the role claim in a oauth token, so when I user creates a new group I'd need to create that group on the auth server and add that group to each user who is invited. This would work I believe but with how Spring Security works would require users to log out and back in, in order to gain the new group.

Is scopes instead another alternative? or would I make use of claims and each new group created would need the user to "authenticate" with the group?

Do I just limit/control access based on what groups the user profile has assigned to it? Seems simple but also doesn't seem the most secure.

I'm sure there is a pretty standard way to handle this I'm just not sure what approach to take.

0

Your problem is that you have "security roles" and "groups" and you don't to make them both the same thing.

ie. If you give people permission to create and modify the security roles, they can give themselves access to all sorts of stuff. ie I make a new role called admin and add myself. Your app uses the admin role to decide who can delete users.

In your case the okta groups are your security roles. You could use them and try prefixing the group name or something in order to keep them seperate. But its a potential hole in your security.

It's probably best to make a separate system which keeps track of your private groups and who belongs to each of them. This is part of your application logic.

  • That makes sense. It's much easier to do this in application logic if that is a 'standard' way of going about such a thing. Thanks for the response. – Chris Turner Aug 16 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.