﻿<?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>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Simon,
  
Yes, RS is infrastructure. How you use it isn't.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment22</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment22</guid><pubDate>Wed, 04 Aug 2010 07:54:56 GMT</pubDate></item><item><title>Simon MacArthur commented on Real world authorization implementation considerations</title><description>So Rhino Security _IS_ infrastructure too? 
  
  
  
TBH I think the debt collection example you use could be better defined with a fairly a simple Workflow process, this would limit  the "negotiators"  by virtue of the actors you set on the "negotiate" activity.  
  
  
You map the Workflow to a "case" entity, this also allows you to delegate to someone not normally permitted by the value rules (for example someone may have experience with that sector, and you feel they may be able to better extract the money)
  
  
It also gives you a baked in mechanism for things like escalation and periodic chase ups.... (as well as maintaining the same security model for the case's lifetime)
  
  
In this case your assertion is correct the Workflow design _IS_ specialised to that task, and therefore not  Infrastructure. :)
  
  
Now we just need a Workflow engine that can handle this... WF4 is not it!
  
  
Si
  
  
  
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment21</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment21</guid><pubDate>Wed, 04 Aug 2010 06:36:47 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Simon,
  
Infrastructure to me mean code that isn't tied to a particular project.
  
In other words, if you have code that you can use in two projects, it is infrastructure
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment20</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment20</guid><pubDate>Tue, 03 Aug 2010 23:13:06 GMT</pubDate></item><item><title>Simon MacArthur commented on Real world authorization implementation considerations</title><description>Second blog comment in one day (massively unusual for me)
  
  
Trying to clarify your distinction between infrastucture and framework.
  
  
I take it you mean "Infrastructure" as in o/s, db, ....  both of which are ultimately frameworks anyway?
  
  
All are exposing a security model, it's just Rhino's is better than the SQL Server / AD, or am I missing a point. (Quite possibly) 
  
  
I would like to see a security model that maps not only entities, but inferred rights imbued due to relationships (both explicit and inferred). 
  
  
Ultimately the "user / security principle" is an entity, the relationship it has with other entities should drive what actions it can perform. E.g you become a manager on a project, you should now be able to see the names of the other people that are  team members on the project.
  
  
Still anything is better than SharePoint's ISecurityTrimmer, and the ugliness of returning 1,000,000 needless items to just discard 999.999 due to permision constraints :)
  
  
Si
  
  
  
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment19</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment19</guid><pubDate>Tue, 03 Aug 2010 21:36:08 GMT</pubDate></item><item><title>Jeremy Wiebe commented on Real world authorization implementation considerations</title><description>I've looked at Rhino Security a little bit when you posted previously about it.  The operation view of things looks similar to how AzMan works.  The one thing that RS adds that is lacking with AzMan is that you pass the entity along which provides powerful context for authorization.  In our current project we've had two instances (could be more yet) where the entity involved in the operation mattered and we had to implement a solution over top of AzMan.  
  
  
Overall though I much prefer the operation-based authorization instead of role-based for systems of any complexity.  
  
  
Good things to keep in mind here though.  Thanks.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment18</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment18</guid><pubDate>Fri, 30 Jul 2010 17:36:05 GMT</pubDate></item><item><title>Cassio Tavares commented on Real world authorization implementation considerations</title><description>I didn't look at Rhino Security until now but I have a restriction to use it. I work at a company and we use few third party frameworks and libraries as possible. You know. 
  
  
Today we use only NH, but I will take a look at RS.
  
  
Thanks
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment17</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment17</guid><pubDate>Mon, 26 Jul 2010 20:03:32 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Cassio,
  
NH Filters aren't suitable for that.
  
You probably want to look at Rhino Security, which does all of that for you.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment16</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment16</guid><pubDate>Mon, 26 Jul 2010 19:32:38 GMT</pubDate></item><item><title>Cassio Tavares commented on Real world authorization implementation considerations</title><description>Ayende, I don't know if you remember but I discussed with you and Fabio about NH filtering subclasses - I had to do it by myself.
  
  
I had exactly these kind of problems of authorization (filtering) and I wanted to use NH filters.
  
  
The advantage to use NH filters is because they're simple to disable in case of a super admin user, for example. But they need more power in my opinion. 
  
  
This reminds me that I complained about one more thing. I have to enable or disable them in my GetSession() method, where I don't have too much information about the context. So I asked you to create a new event where I could enable or disable filters just before NH build the query.
  
  
Do you remember? What do you think?
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment15</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment15</guid><pubDate>Mon, 26 Jul 2010 19:20:33 GMT</pubDate></item><item><title>Szymon Kulec commented on Real world authorization implementation considerations</title><description>That truely clarifies your point of view. I'll think about it :) 
  
  
Take care
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment14</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment14</guid><pubDate>Mon, 26 Jul 2010 17:03:13 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Szymon,
  
Not that way, no. That invert the association, because that states what the CONDITIONS for the operation are.
  
I don't care about this, I want to state if the op is permitted, and the condition executed by the infrastructure.
  
Something like:
  
Security.IsAllowed("/Order/Approve", entity, user)
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment13</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment13</guid><pubDate>Mon, 26 Jul 2010 08:46:54 GMT</pubDate></item><item><title>Szymon Kulec commented on Real world authorization implementation considerations</title><description>Ayende,
  
by saying 'a _lot of different context' I understand a logic operation (for instance: concatenation) on the mentioned conditions. Would you express them as a composite condition, like (using specifications)
  
  
if (new IsCustomerGoldSpec (customer) &amp;&amp; new HitOrderLimit(customer))
  
  
in your code, or maybe you would try to hide it in some way?
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment12</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment12</guid><pubDate>Mon, 26 Jul 2010 08:22:28 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Szymon,
  
_How_ you implement filtering is a separate topic.
  
Yes, you certainly want _that_ to be an infrastructure piece.
  
But the problem is how you provide enough context to make things useful.
  
  
As for the idea of a scope.
  
Consider how much more messy it is to write the code for the second scenario that I have in the post with explicit scopes.
  
Then consider the fact that this is a highly simplified scenario, and real world scenarios may requires a _lot_ of different contexts for different parts of the operation
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment11</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment11</guid><pubDate>Sat, 24 Jul 2010 11:36:40 GMT</pubDate></item><item><title>Szymon Kulec commented on Real world authorization implementation considerations</title><description>Have you considered moving the authorization to the infrastructure partially? For instance viewing rights can be easily implemented as filters for quering. I took part in implementing a system, where, for the specific cases, even some properties could have been configured, to be shown/hidden.
  
  
Speaking about the context, have you ever tried move the authorization to the infrastructure and use some kind of a scope, as the current operation context provider?
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment10</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment10</guid><pubDate>Sat, 24 Jul 2010 11:33:25 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Configurator,
  
LAN app talking to a DB directly have only two modes:
  
There is not security (since the users can connect to the DB directly and issue whatever query they want)
  
There is a need for security, and the only way to apply it (and business rules, for that matter) is in the infrastructure. That means either using some Row Level Security feature or stored procedures.
  
I outlined the problems with infrastructure level security in this post, and I think that the problems with SP are well documented by now.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment9</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment9</guid><pubDate>Fri, 23 Jul 2010 19:44:42 GMT</pubDate></item><item><title>Cassio Tavares commented on Real world authorization implementation considerations</title><description>Hi configurator. 
  
  
&gt;Why should a Winforms LAN app never talk to the DB directly?
  
  
it is not secure because every user of your app has direct access to the DB server. But....You gotta do what you gotta do.
  
  
Besides that, Ayende's post has more concern about enterprise applications. At least I think it is. lol.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment8</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment8</guid><pubDate>Fri, 23 Jul 2010 18:59:03 GMT</pubDate></item><item><title>configurator commented on Real world authorization implementation considerations</title><description>Why should a Winforms LAN app never talk to the DB directly?
  
  
And who says a single machine is the same as a single user?
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment7</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment7</guid><pubDate>Fri, 23 Jul 2010 17:30:56 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>David,
  
The place to ask is in the rhino tools dev mailing list
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment6</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment6</guid><pubDate>Fri, 23 Jul 2010 13:29:58 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>Configurator,
  
A single user app uses no security.
  
A multi user app shouldn't talk directly to a DB, that arch died in the mid 90s
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment5</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment5</guid><pubDate>Fri, 23 Jul 2010 13:29:40 GMT</pubDate></item><item><title>David W Martines commented on Real world authorization implementation considerations</title><description>Ayende, 
  
You mentioned Rhino security.  I love it, but I want to use Linq (not ICriteria).  Do you think you will ever modify it for Linq or do you know if anyone else already has?  Thanks.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment4</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment4</guid><pubDate>Fri, 23 Jul 2010 13:14:57 GMT</pubDate></item><item><title>configurator commented on Real world authorization implementation considerations</title><description>I too agree with the point of the article, but you seem to be ignoring a major software use-case - not all software runs on a webserver. There could be client (winforms) apps that connect to the database.
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment3</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment3</guid><pubDate>Fri, 23 Jul 2010 12:43:17 GMT</pubDate></item><item><title>Ayende Rahien commented on Real world authorization implementation considerations</title><description>LL,
  
That is a good point, which I assume resolve the problem of connection pooling.
  
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment2</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment2</guid><pubDate>Fri, 23 Jul 2010 09:43:07 GMT</pubDate></item><item><title>LL commented on Real world authorization implementation considerations</title><description>Hi,
  
  
One correction: Oracle (and possibly other databases as well) has the concept of a _proxy user_, which allows application servers to login with one set of credentials _on behalf_ of other users. The combination of proxy users, row-level security and connection pools works quite well in Oracle.
  
  
This does not invalidate the general point of the article, with which I fully agree.
  
  
LL
</description><link>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment1</link><guid>http://ayende.com/4559/real-world-authorization-implementation-considerations#comment1</guid><pubDate>Fri, 23 Jul 2010 09:21:56 GMT</pubDate></item></channel></rss>