Our application has four authorization roles:
- Anonymous, or users of our application that are not logged in.
- Portal, or our customers that we serve.
- Lawyer, or our network of affiliate attorneys.
- Admin, or the Neon Law team, supervised by in-house attorneys.
These roles are assumed by users (if you are not logged in, you are an anonymous user right now) and correspond to Postgres roles in our api, and the data you can access here at NeonLaw.com.
In the diagram above, you'll see that an admin can do everything, a lawyer can do a subset of what admin can do, a portal user can do a subset of what lawyers can do, and anonymous users can do a subset of what portal users can do. We scope each API request to one of these four roles, which provides us a way to ensure the right people are getting the right information.
While other systems have complex authorization schemes, ours does not need to be more complicated than this. We've found that a tiered authorization scheme is sufficient for the vast majority of authorization use cases. In our case it is sufficient because it solves all use cases and we can rely on policy, or the ethical standards that lawyers hold themselves accountable too (known as the Model Rules of Professional Conduct) to ensure that even if a lawyer or a person a lawyer supervises accesses information that they shouldn't, they have an obligation to report their access to that information or otherwise be subject to penalties.