Stripe is a platform that allows companies of all sizes to accept payments, issue invoices and generally manage their billing. Their offering is necessarily a bit complex, and they have a roles structure to match.

Every user can have a combination of roles that allows them access to certain features and functionality within the product. When you invite a user you’re presented with a list that looks like this:

All in all, there are 14 roles to choose from, plus a default 15th role (Owner) that is automatically assigned to whoever creates the account and cannot be assigned to another person.

In this article, we’ll walk you through how to recreate Stripe’s Roles model using PropelAuth. In order to follow this tutorial, first create a PropelAuth account, and then navigate to the Roles & Permissions page within the dashboard.

Single Role vs Multi-Role

PropelAuth allows for two separate role models - single, where a user can only be assigned one role at a time, and multi, where a user can have multiple roles.

The default in PropelAuth is single role, so before we begin, we’ll need to switch to multi-role. This can be done via the Configuration button on the Roles & Permissions page.

Adding Roles

Next, we’re going to want to add in all of our Stripe roles via the Add Role button.

The Add Role modal lets you choose the name of your role, as well as select which other roles it can manage (basically: which other users can this role modify access for).

The majority of Stripe’s roles don’t interact with other roles, so we’ll go ahead and leave that blank:

And once we click Add, we’ll see it appear in the list:

PropelAuth has the concept of a Default role - a role that is automatically assigned to a user when they join the org if no other role has been given (this can happen if they join via a domain match or SAML login). Let’s go ahead and make View Only the default by expanding it, clicking the Gear icon and choosing “Set as Default Role.”

After we’ve done that, we can see that our list is now updated.

Next, we’ll go ahead and keep adding roles the same way. The Administrator and IAM Administrator roles will be a bit different - these roles have access to manage other users.

Once we’ve done all of that, we’re going to want to make one last change - updating the pre-existing Owner role to be able to manage users as well. Since it was created before we added all of these additional roles, it only has access to manage itself.

To make the changes we need, we’ll expand it, click the gear icon and select Edit Role.

And then we’ll be able to give it access to manage all of the other roles.

Once we do that, we can easily see the change in the expanded role view:

User-Facing Interactions

Okay - so we’re all set up. Let’s see how this impacts our users.

I’ve created an account, jane@doe.com, and logged in. She is the first person in her organization, so she has been automatically assigned the Owner role, which can easily be seen from her Users page on the PropelAuth hosted pages:

Now, let’s invite another user to her organization - john@doe.com. Because jane@doe.com has the power to manage all of the roles, she can see and choose from the entire list. Let’s give John the View Only role:

Note: PropelAuth does not enforce that there can only be one Owner role, but does enforce that at least one person must be designated as an Owner within an organization.

Now that John has an account, let’s log in and see what he sees:

His view is a bit different to reflect his permissions - he can only see the members of his organization, and he cannot edit them, or invite others.

Custom Permissions

By default, PropelAuth provides a set of permissions related to PropelAuth itself - things like the ability to invite users, manage SAML connections, etc.

You can also create custom permissions to manage access within your own application.

Let’s use Stripe’s Developer role as an example:

Looks like we need to add a permission around accessing a secret key. To do so, we return to the Roles & Permissions page in PropelAuth, select Configuration → Configure Permissions.

A side panel will open, where we can add a new permission and assign it to a role:

And now, when we expand the Developer role within the list, we’ll be able to see that it has access to the canAccessSecretKey permission:

When an engineer goes to write code, they can write:

// This will be different in each language
user.hasPermission(organization, "canAccessSecretKey")

and this will take into account the role the user has to determine whether they can access the secret key.

More Reading

If you’d like to learn more about roles & permissions in PropelAuth, check out our documentation here.

If you’re interested in reading more about how to design your product’s RBAC, check our our guide here.