Dealing with complex authentication and authorization frameworks is also hard. The solution to authentication and authorization is rarely picking a framework and then calling it a day. If you don't know how the framework works and what its failure modes are, you are likely to make some mistakes.
I was taught one useful thing about security: the triple gold (AU) standard; which refers to the need to do authentication, authorization, and auditing. People seem to always forget about the latter but it's actually equally important. If bad people try to get in, you need to know. If there's a security bug causing people to get in that shouldn't, you need to know. Etc. That's auditing. Being able to audit what happens and who is authenticated and authorized for what and why is important and quite often also a legal requirement.
I always start from that angle: so I need detailed security logs with context I can make sense of. I need observable software basically.
I've implemented custom role based security in various projects. It's not that hard but you need to understand some basic design patterns. Users have context. That context includes roles that are associated with privileges that have a particular scope in which they apply. It's basically the set of parameters that drive the calculation of which list of privileges this user has; which is a function that has to live somewhere and that needs to be tested extremely thoroughly.
You assign roles to users but you verify privileges. This keeps decouples user management from policy changes. The process of authorization is verifying that a given principal has the right privileges given their user context and the context of the privilege (the requested scope). The process of authentication is verifying the user's identity and then bootstrapping the user context.
If you use JWTs or similar technology, you can actually serialize that user context, sign it, and pass it around. That's why they are so popular in micro services. It also leads to an unfortunate tendency of developers to confuse authentication and authorization. Checking the signature is valid would be authenticating; using the signed information for granting or denying access would be authorizing.
Where it gets hard is that some authorization logic is conditional on things outside the user context. Like the request they are making, the time of day, some business context they have, or the state of a particular thing. This is where bad things happen when developers who don't understand this topic deeply get a little bit creative to meet the requirements.
I was taught one useful thing about security: the triple gold (AU) standard; which refers to the need to do authentication, authorization, and auditing. People seem to always forget about the latter but it's actually equally important. If bad people try to get in, you need to know. If there's a security bug causing people to get in that shouldn't, you need to know. Etc. That's auditing. Being able to audit what happens and who is authenticated and authorized for what and why is important and quite often also a legal requirement.
I always start from that angle: so I need detailed security logs with context I can make sense of. I need observable software basically.
I've implemented custom role based security in various projects. It's not that hard but you need to understand some basic design patterns. Users have context. That context includes roles that are associated with privileges that have a particular scope in which they apply. It's basically the set of parameters that drive the calculation of which list of privileges this user has; which is a function that has to live somewhere and that needs to be tested extremely thoroughly.
You assign roles to users but you verify privileges. This keeps decouples user management from policy changes. The process of authorization is verifying that a given principal has the right privileges given their user context and the context of the privilege (the requested scope). The process of authentication is verifying the user's identity and then bootstrapping the user context.
If you use JWTs or similar technology, you can actually serialize that user context, sign it, and pass it around. That's why they are so popular in micro services. It also leads to an unfortunate tendency of developers to confuse authentication and authorization. Checking the signature is valid would be authenticating; using the signed information for granting or denying access would be authorizing.
Where it gets hard is that some authorization logic is conditional on things outside the user context. Like the request they are making, the time of day, some business context they have, or the state of a particular thing. This is where bad things happen when developers who don't understand this topic deeply get a little bit creative to meet the requirements.