﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>uzivatel commented on RavenDB Authorization Bundle Design</title><description>@ayende: wow that's great! RavenDB rocks!
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment19</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment19</guid><pubDate>Fri, 30 Jul 2010 22:07:26 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Uzivatel,
  
Someone created a membership provider for raven.
  
If you ask in the user group, maybe he'll share it.
  
  
And yes, it is entirely possible
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment18</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment18</guid><pubDate>Fri, 30 Jul 2010 21:08:05 GMT</pubDate></item><item><title>Uzivatel commented on RavenDB Authorization Bundle Design</title><description>a real off-topic (the theme is close), what would you suggest as a membership provider for ASP.NET MVC v2 project using RavenDB ?
  
  
I don't really know if it is possible to write membership provider against RavenDB datastore, so in the end I end up using some "SQL" database anyway (say Postgre), which I wouldn't want (due to scalability and I want to rely completely on RavenDB only).
  
  
Thanks
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment17</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment17</guid><pubDate>Fri, 30 Jul 2010 18:21:27 GMT</pubDate></item><item><title>Jonas commented on RavenDB Authorization Bundle Design</title><description>OK Thanks ;)
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment16</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment16</guid><pubDate>Wed, 28 Jul 2010 08:44:21 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Jonas,
  
I don't. The client doesn't talk to Raven.
  
The client make requests to the app server to do some application operation.
  
The app server then does it things, and uses the user context and the current operation to decide what security should be applied.
  
  
Then the auth bundle enforces that decision.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment15</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment15</guid><pubDate>Wed, 28 Jul 2010 08:41:03 GMT</pubDate></item><item><title>Jonas commented on RavenDB Authorization Bundle Design</title><description>Ayende,
  
  
:-) 
  
  
1) OK so "someone" can talk to the app server. (that would be my client code)
  
2) The app server will "forward" this request to RavenDB. behind the firewall
  
  
How do you ensure that the message going from my client to your app server is "kosher"????
  
  
/Jonas
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment14</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment14</guid><pubDate>Wed, 28 Jul 2010 08:35:55 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Jonas,
  
A _user_ can't access RavenDB, because there is a firewall in the middle.
  
The app can, because the firewall allows it.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment13</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment13</guid><pubDate>Wed, 28 Jul 2010 08:26:13 GMT</pubDate></item><item><title>Jonas commented on RavenDB Authorization Bundle Design</title><description>I'm still confused..... If "no user can access RavenDB" how can your app server access it????
  
  
/Jonas
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment12</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment12</guid><pubDate>Wed, 28 Jul 2010 08:17:08 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Jonas,
  
&gt;  how in the world do you ensure this??? (trusting the client)
  
  
That is simple, _you_ are the client :-)
  
  
In other words, this is applicable when you have:
  
  
User -} App Server -} RavenDB
  
  
And no user can access RavenDB directly. 
  
Since we wrote the app server code, we know that we can trust it.
  
  
That is an extremely common deployment scenario, so that is not a big issue.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment11</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment11</guid><pubDate>Wed, 28 Jul 2010 07:29:48 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Tobi,
  
No, it can't really be done in an agnostic way.
  
Rhino Security and RavenDB Authorization Bundle both share the same general logic, but the implementation is drastically different because of the different nature of the two data stores.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment10</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment10</guid><pubDate>Wed, 28 Jul 2010 07:27:04 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Rafal,
  
  
&gt; What does 'Operations/Debt/Finalize' permission mean for a document db? 
  
  
Absolutely nothing!
  
It isn't the DB that gives meaning to this, but the application using it.
  
Doing read/write/delete/query permissions leads to exactly the type of system that I described in my earlier post.
  
  
You _can_ write to the document to add background information about the debt, but you can't write to the document to finalize the debt.
  
If you are limited to just "write" permission, then this is useless in most common business scenarios.
  
  
This is how Rhino Security has been working for a long time, and it works, very nicely, too.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment9</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment9</guid><pubDate>Wed, 28 Jul 2010 07:25:10 GMT</pubDate></item><item><title>Jonas commented on RavenDB Authorization Bundle Design</title><description>Sorry if I'm missing something obvious but how in the world do you ensure this??? (trusting the client)
  
  
"Since we can trust the client calling us"
  
  
Thanks
  
/Jonas
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment8</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment8</guid><pubDate>Wed, 28 Jul 2010 04:36:24 GMT</pubDate></item><item><title>tobi commented on RavenDB Authorization Bundle Design</title><description>And I just realize that I am in line with Rafal. I think the only Raven specific thing about this model is the filtering of documents. Ayende, could that be done at the client level too or would that be much slower? How would you implement it? Could you leverage server-side caches or a more efficient algorithm? At first sight it would seem that you would have to make a loop join to the authorization documents that could be done at the client level too by making a second request.
  
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment7</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment7</guid><pubDate>Tue, 27 Jul 2010 20:19:08 GMT</pubDate></item><item><title>tobi commented on RavenDB Authorization Bundle Design</title><description>This security model is very general and yet simple and pragmatic. I really like it. However this hat little to do with RavenDB. Nothing in this concept depends on it (except filtering documents), it could easily be generalized to any IAuthorizationStore. So I would advocate implementing it as a provider-agnostic lib first.
  
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment6</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment6</guid><pubDate>Tue, 27 Jul 2010 20:13:27 GMT</pubDate></item><item><title>Rafal commented on RavenDB Authorization Bundle Design</title><description>@Ayende
  
I don't think so. You've pushed some idea of 'permissions' into Raven that are meaningless for a document database. What does 'Operations/Debt/Finalize' permission mean for a document db? Nothing, I suppose. I think there should be a fixed set of  operations relevant to a document db (read, insert, update, delete, query, etc) and the authorization implementation should allow you to grant/deny rights to execute these operations using Raven API. In your approach you just moved a part of application's logic into the database, but it's not a complete security solution - you'll have to duplicate some security code in application anyway.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment5</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment5</guid><pubDate>Tue, 27 Jul 2010 17:10:32 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Bob,
  
That is why it is optional, you have to explicitly want to use security for this behavior to kick in.
  
And note that there is a difference between filter a query and accessing a secured document explicitly.
  
In the first case, we assume that you want to query stuff and filter out things you don't have access to.
  
In the second, you obviously trying to access something that you don't have rights to, at which point we throw.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment4</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment4</guid><pubDate>Tue, 27 Jul 2010 15:14:37 GMT</pubDate></item><item><title>Ayende Rahien commented on RavenDB Authorization Bundle Design</title><description>Rafal,
  
Two distinct things. The first is how you _use_ authorization, how you set things up, etc.
  
The second is how you _implement_ authorization, and _that_ should be in the infrastructure. 
  
Using auth should be a high level concept.
  
  
Rhino Security &amp; the Authorization Bundle design both fall into this campl.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment3</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment3</guid><pubDate>Tue, 27 Jul 2010 15:11:22 GMT</pubDate></item><item><title>Bob commented on RavenDB Authorization Bundle Design</title><description>'When performing a query over a set of documents, some of which we don’t have the permission for under the specified operation, those documents are filtered out from the query.'
  
  
-I can see why it would behave this way but it could be nasty as it is sort of a 'silent' failure. Security concerns are effectively filtering the data set. Maybe a hard error should be configurable?
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment2</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment2</guid><pubDate>Tue, 27 Jul 2010 12:46:51 GMT</pubDate></item><item><title>Rafal commented on RavenDB Authorization Bundle Design</title><description>How this relates to your recent post about not relying on infrastructure handling the authorization? I thought the application server is supposed tohandle authorization, Raven is clearly a part of infrastructure here and shouldn't be involved in auth at all.
</description><link>http://ayende.com/4563/ravendb-authorization-bundle-design#comment1</link><guid>http://ayende.com/4563/ravendb-authorization-bundle-design#comment1</guid><pubDate>Tue, 27 Jul 2010 12:30:15 GMT</pubDate></item></channel></rss>