It seems that most enterprise applications I've worked with have very different approaches, and I'm wondering if there are best practice/time-tested architectures or resources. Thank you!
Ask HN: How would you design an enterprise (B2B) user permissioning system?
1–4 of 4 posts
Re: Ask HN: How would you design an enterprise (B2B) user permissioning system?
#2Something to do with Posgres row-level-security as an ACL would be amazing. Otherwise Identity Server is a good foto for in house, and AWS AMI for serverless.
Re: Ask HN: How would you design an enterprise (B2B) user permissioning system?
#3Authentication or authorization? If it's the latter, I'd model it on what AD/LDAP do: folders/OUs for hierarchy, groups for crossing hierarchy boundaries, then users and securables as objects in the directory. Then on top of that, be able to assign permissions such that node (OU/group/user) -> can-do-action -> other node. Then child nodes inherit permissions as well. We're using something similar in a system I worked on and sys admins and end users are pretty comfortable with it since it used the same paradigms they're used to. You can also use the same thing for multi-tenancy by just creating OUs for tenants.
For authentication, whatever supports ADFS, SAML and/or OIDC. It's a big plus when they can use existing credentials or SSO into your system from theirs.
Re: Ask HN: How would you design an enterprise (B2B) user permissioning system?
#4Most of what you describe probably can be attributed to the fact that there used to be (and still are to some extent) quite a few competing identity server software providers.
The enterprise world tends to move more slowly than the rest of the world (or at least it often seems that way), which is why older systems and practices frequently are still in use.
If available I'd make use of existing Active Directory / LDAP systems (as ilkhan4 has already pointed out) for authorization.
For authentication Kerberos (often used in conjunction with Active Directory / LDAP) is an elegant way for implementing single sign-on (SSO) because it allows the user to simply authenticate with her normal user account in the local OS. Afterwards, the user's automatically logged in to every application on the local network that uses Kerberos for authentication (basically, by sharing a token).
Other than that, the usual best practices apply (such as not storing plaintext passwords). Depending on your architecture, techniques common outside of the enterprise world like transferring information via JSON Web Tokens are useful, too.