One thing you could do is to keep things as simple as possible inside the application but code "confirmation pages" into every restricted flow. So the confirmat

One thing you could do is to keep things as simple as possible inside the application but code "confirmation pages" into every restricted flow. So the confirmation page (or controller/Form object/Service/what have you) is what contains the authorization logic, not the main action flow. So every time you have a particularly sensitive action, you just give that action another step, in which you store your messy authorization code. A fun benefit to doing it this way is that you can 1) if they have permission, you can make the extra step totally transparent to the user with redirects and 2) if they don't, it also gives you the chance to explain fully why they can't do the thing they wanted to do in a whole nother page. Try to avoid having a big authorization control center as long as possible. Really when enterprise people request these things, they're trying to account for very specific edge cases in their previous apps that they got burned on. They don't really want to experiment and play with every possible combination of roles and permissions. If they absolutely insist on having an Excel-like spreadsheet of users and permissions to play with, then just import an Excel spreadsheet and enforce any sort of arbitrary format on them you want. Just two cents, not bulletproof advice by any means.