|
|
|
|
|
by bbor
618 days ago
|
|
A) fair, b) I think this common distinction is a little overblown. Authorization is just a particularly straightforward CRUD feature, perhaps with some inheritance logic — authentication seems to be where 99% of all security sadness comes into play. Plus there’s the less-often-discussed task of protecting some of your users from other users, such as Google vetting their html5 ads for malware, and military (all B2B?) contractors trying to write tools that aren’t useful to insider threats. It’s worse than either auth* domain IMO, as it usually involves unavoidable tradeoffs for benign users; I haven’t read this book in full but I suspect it didn’t make the list! TBF, I’m not sure it even has a standard name yet like the other two… anyone know enough to correct me? Maybe… “encapsulation”? “Mitigation”? The only “auth*” term left is arguably “authorship”, which doesn’t really fit https://www.thefreedictionary.com/words-that-start-with-Auth Edit; I think I just taught myself what complex authorization is! I’ve always treated it as role management, but “what roles can do what” does also fit, I have now realized. Sorry y’all - leaving it up in case it’s a learning experience for others lol |
|
There's also lots of potential levels of granularity and thus complexity, with the most granular (that I've seen) being able to model access through time as a continuum down to the individual field of each object in the business, based on wide arrays of arbitrary other factors. Think modeling problems like:
> "If condition X in the business is true then I want user X to be unable to view/edit the 'foobar' field of entity 'powzap', and I only want this rule to be true on Tuesdays of the months April and October".
That's a tough problem to tackle with a lot of subtlety to wrangle.