DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Data Engineering
  3. Databases
  4. How the RavenDB Authorization Bundle Operates

How the RavenDB Authorization Bundle Operates

Oren Eini user avatar by
Oren Eini
·
Apr. 10, 12 · Interview
Like (0)
Save
Tweet
Share
4.88K Views

Join the DZone community and get the full member experience.

Join For Free

the question came up several times in the mailing list with regards to how the ravendb authorization bundle operates, and i think it serves a broader discussion.

let us imagine a system where we have contracts, which may be in several states:

  • mine – contracts that an employee signed.
  • done – standard users can view, lawyers assigned to the company can sign.
  • draft – lawyers can view / edit, partners can approve.
  • proposed – lawyers can create / edit, but only the lawyer that created it can view it, partners can accept.

so far, fairly simple, right? except the pure hell that you are going to get into when you are trying to show the users all of the contracts that they can see, sorted by edit date and in the nda category.

why am i being so negative here? well, let us look at what we are going to have to do in the most trivial of cases:

image

in this sort of system, we are going to have to show the user all of the contracts that they are allowed to see, and show them some indication what operations they can do on each.

the problem is that generating this sort of view is expensive . especially when you have large amount of data to work through. more interesting, from a ux perspective, it also doesn’t really work that well. most users would want a better separation of the things that they can do, probably something like this:

image

this allows us to do a first level filtering on the data itself, rather than try to apply security rules to it.

in the first case, we need to get all the contracts that we are allowed to see. the security rules above are really simple, mind. but trying to translate them into an efficient query is going to be pretty hard. both in terms of the code requires and the cost to actually perform the query on the server. there are other things that are involved as well, such as paging and sorting in such an environment.  i have created several such systems in the past, rhino security is probably the most well known of them, and it gets really hard to optimize things and make sure that everything works when you start getting more complex security rules (especially when you have a user editable security system, which is a common request).

the second case is cheaper because we can limit the choices that we see in the query itself. we may still need to apply security concerns, but those goes through the query directly, rather than a security sub system. this kind of change usually force people to be more explicit in what they want, and it result in a system that tends to be simpler. the security rules aren’t just something arbitrary that can be defined, they are actually visible on the screen (my contracts, drafts, etc). changing them isn’t something that is done on an administrator’s whim.

yes, this is a way to manage the client and their expectations, but that is important . but what about the complex security that they want?

that might still be there, certainly, but that would be active mostly for operations (stuff that happen on a single entity), not on things that happen over all entities. it is drastically easier to make a single entity security decisions work efficiently than make it work over the whole set inside the database.

security authentication Database

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Best Use Java Records as DTOs in Spring Boot 3
  • Low-Code Development: The Future of Software Development
  • Getting a Private SSL Certificate Free of Cost
  • Keep Your Application Secrets Secret

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: