﻿<?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>Zdeslav Vojkovic commented on Convention based security: A MonoRail Sample</title><description>I use this solution (simplified) to filter entities based on permissions: 
  
In the application layer I have service methods like:
  
[RequiresPermission("Group/Edit")]
  
void SomeMethod( ... parameters...) {}
  
  
Services have SecurityInterceptor implemented through Windsor/DP2 which check for RequiresPermission attribute and do something like:
  
CallContext[Context.Security] = new SecurityContext(CurrentUser, attr.Permission);
  
  
than in the Repository implementation, I add the permissions to query:
  
public IList&lt;T&gt; Find(IQuerySpecification query)
  
{
  
	AddPermissions(query, CallContext[Context.Security]);
  
	return GetCriteria(query).List&lt;T&gt;();
  
}
  
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment11</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment11</guid><pubDate>Thu, 24 Jan 2008 08:14:42 GMT</pubDate></item><item><title>Peter commented on Convention based security: A MonoRail Sample</title><description>Yes, I assume that the users are also a persisted entity, as is the group, like your original model.  I don't know that there is a great way to integrate with an external store although that seemed to come up frequently in my experience.  You could query the authorization tables, then query the remote user store with the results but you can't use the 'in group' clause if the groups are also external.  In that case, you probably have to replicate at least part of the user/group data model locally.
  
  
Aside from the functional permissions (role permissions) and operations on specific entities, the use cases that I saw most frequently were:
  
  
1. Listing entities that the requesting user (or group containing user) has x permissions on, as in your example.
  
  
2. Permission Management:  In a multi-user system where you can create or manage entities and 'share' them, you request access to all the groups and users that you can see, in order to give them those permissions.  This permission set is limited by your own access rights to the entity.
  
  
3. Views of entities (paged) with the permissions for the requesting or specified user.  So, return the list of entities where I have Read | Write | Delete permission.  This is to see a quick list of the permissions along with the entity (ID, CanRead, CanEdit, CanDelete).
  
  
By the way, how many people are you?  No single human can post this much AND produce all this code (and hold a job)!
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment10</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment10</guid><pubDate>Thu, 24 Jan 2008 00:39:30 GMT</pubDate></item><item><title>Ayende Rahien commented on Convention based security: A MonoRail Sample</title><description>Marco,
  
Multiply clients will hit the same data source, possibly with distributed cache involved to make it faster.
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment9</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment9</guid><pubDate>Wed, 23 Jan 2008 23:28:32 GMT</pubDate></item><item><title>Ayende Rahien commented on Convention based security: A MonoRail Sample</title><description>Peter,
  
I'll post an implementation discussion soon.
  
Your query assumes that Users are also persisted entity right?
  
If we can get them through NHibernate, it is simply:
  
  
DetachedCriteria allUsers = DetachCriteria.For&lt;User&gt;();
  
authorizationService.AddPermissionsToQuery(CurrentUser, "/Group/Edit", allUsers);
  
FindAll(allUsers);
  
  
If they arrive from external store, you would need to loop on them, I am afraid.
  
I suppose I can add a way to get the ids of all the users that you can access, but I would like to hear more concrete reasoning for that.
  
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment8</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment8</guid><pubDate>Wed, 23 Jan 2008 23:27:57 GMT</pubDate></item><item><title>Marco commented on Convention based security: A MonoRail Sample</title><description>oeps.. i see that you (partly) answered my question in the previous post...
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment7</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment7</guid><pubDate>Wed, 23 Jan 2008 22:12:48 GMT</pubDate></item><item><title>Marco commented on Convention based security: A MonoRail Sample</title><description>@Peter.. it's already there see https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-security
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment6</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment6</guid><pubDate>Wed, 23 Jan 2008 22:09:36 GMT</pubDate></item><item><title>Marco commented on Convention based security: A MonoRail Sample</title><description>Nice.. One addition.. add the "why" to the DenyAccess
  
DenyAccessToAction(authorizationService.GetAuthorizationInformation(user, operation);
  
  
On to the next step ;-) suppose i want to block reading a single property..Would you handle that in the view? the same for an update
  
  
How would you handle this when you have multiple different clients (web / windows form / webservice) and the same security layer should be active?
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment5</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment5</guid><pubDate>Wed, 23 Jan 2008 22:07:28 GMT</pubDate></item><item><title>Ayende Rahien commented on Convention based security: A MonoRail Sample</title><description>Francois,
  
Those types of constraints are usually expressed with entities groups and matching users groups in Rhino Security.
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment4</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment4</guid><pubDate>Wed, 23 Jan 2008 21:10:02 GMT</pubDate></item><item><title>Peter commented on Convention based security: A MonoRail Sample</title><description>Ayende, awesome posts on this subject.  There really isn't much discussion out there.  I put together a similar system a while ago and have been thinking about the redesign.  I commented about the original here (last comment): http://www.ayende.com/Blog/archive/2007/08/05/Alas-security-is-a-business-concern.aspx
  
  
I think of this as an Access Control model.  Could you post the final data model for the system?  I think of each permission row in the permissions table as ACL Entries; the EntitySecurityKey as the grouping mechanism to tie them together (like an aclid).  Am I understanding correctly?
  
  
Also, this is an 'internal' security solution, as I read it.  Meaning that you have to join against the permissions table when building up your entities, right?  What do you think about a query like "Get all the users in groups on which I have 'Group.Edit' permission"?  What about when the user store is external (LDAP, or other)?  
  
  
Peter
  
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment3</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment3</guid><pubDate>Wed, 23 Jan 2008 20:58:13 GMT</pubDate></item><item><title>Bunter commented on Convention based security: A MonoRail Sample</title><description>Rather robust and dirty indeed. My first idea was "this will not work on many cases" but when I think of the apps I've done, concept itself would probably be sufficient in 90% of the cases. Simple and neat, as usual for things in your blog :)
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment2</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment2</guid><pubDate>Wed, 23 Jan 2008 20:51:48 GMT</pubDate></item><item><title>Francois Tanguay commented on Convention based security: A MonoRail Sample</title><description>Sounds good to me. I did the same thing in the past at the service layer instead of the mvc since I think security isn't a matter of presentation.
  
  
Operation would be deduced from the Service method being called.
  
  
What I found important is to have a hook/extension point (or really nice object constraint language) for security scenarios containing lots of business logic.
  
  
e.g.: An employee can view an account if he works for the same branch as the the account's branch, a parent branch or a branch connected through related branches and that branch connection isn't expired.
</description><link>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment1</link><guid>http://ayende.com/3111/convention-based-security-a-monorail-sample#comment1</guid><pubDate>Wed, 23 Jan 2008 20:46:11 GMT</pubDate></item></channel></rss>