How to model our access control requirements with Crowd?

[Geoff Bland]

I've been asked to look at Crowd to replace our current access control mechanism.

I'm having some trouble getting my head around how we can use Crowd to meet our requirements so would appreciate some advice about how to model this in Crowd.

Our current access control is based on a matrix of groups, users and permissions. We have 5,000 users about 1,000 groups and each group has 7 permissions; ADMIN, MANAGE, FWD, RWD, TYPE, VIEW, READONLY. The ADMIN permission is special as it means this user can add/change/remove users in this group, all the other permissions are meaningful to what our application allows users to do.

So for example, for GROUP_999:

• Alice is allowed  ADMIN, MANAGE, FWD, RWD, TYPE, VIEW, READONLY,
• Bob is allowed MANAGE, FWD, RWD, TYPE, VIEW, READONLY,
• Claire is allowed TYPE, VIEW, READONLY,
• Dave is allowed READONLY,
• Eric is allowed FWD, RWD.

These users can also have different permissions on other groups too.

Crowd seems to allow use to manage users and groups but does not seems to allow us the level we need for what we’re calling permissions. I can see that we could create 7 groups for each of our application groups (GROUP_999_ADMIN,  GROUP_999_MANAGE, GROUP_999_FWD, etc) but that seems clunky.

[Timothy · Accepted solution]

Crowd does not provide permissions to applications. Crowd is a user, group and memberships which are then sycned to the applications linked to it. It is up to the applications that link to Crowd to apply the permissions.

[Geoff Bland]

Thanks for the quick answer, I suspected as much & good to know I wasn't missing something.

So to confirm my understanding, using the example above, I can use Crowd to lookup user/principle Bob and see that he belongs to the group GROUP_999.

But then it is up to my application to determine what Bob is allowed to do in GROUP_999.

[Timothy]

Yup. That's the way it should work.