<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: LDAP-based RBAC with ActiveLdap and declarative_authorization</title>
	<atom:link href="http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/</link>
	<description>Enrico on programming, living, and everything in between</description>
	<lastBuildDate>Tue, 22 Jun 2010 16:13:06 -0400</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Enrico</title>
		<link>http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/comment-page-1/#comment-2184</link>
		<dc:creator>Enrico</dc:creator>
		<pubDate>Fri, 29 Jan 2010 22:35:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.liveandcode.com/?p=271#comment-2184</guid>
		<description>Yeah, looking into it, caching things the way I was only kept the information stored for the request and not for the entire session as I previously thought.

So you&#039;re storing the role information in the database, then?

It seems that the biggest obstacle to caching the role information in the session properly is that declarative_authorization expects the roles to be defined in the User model but Authlogic doesn&#039;t store the User instance in the session directly. Depending on your session storage mechanism, storing the User instance might be impractical.

Out of curiosity, which lower-level Ruby LDAP library are you using? My posts set up ActiveLdap with net-ldap but I&#039;ve actually switched to ruby-ldap (ActiveLdap supports both!) because I was having an issue similar to yours with Active Directory where looking up an entry would fail after the connection had been idle for a while. If you&#039;re using net-ldap, try switching to ruby-ldap and see if it works better for you.</description>
		<content:encoded><![CDATA[<p>Yeah, looking into it, caching things the way I was only kept the information stored for the request and not for the entire session as I previously thought.</p>
<p>So you&#8217;re storing the role information in the database, then?</p>
<p>It seems that the biggest obstacle to caching the role information in the session properly is that declarative_authorization expects the roles to be defined in the User model but Authlogic doesn&#8217;t store the User instance in the session directly. Depending on your session storage mechanism, storing the User instance might be impractical.</p>
<p>Out of curiosity, which lower-level Ruby LDAP library are you using? My posts set up ActiveLdap with net-ldap but I&#8217;ve actually switched to ruby-ldap (ActiveLdap supports both!) because I was having an issue similar to yours with Active Directory where looking up an entry would fail after the connection had been idle for a while. If you&#8217;re using net-ldap, try switching to ruby-ldap and see if it works better for you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Wakefield</title>
		<link>http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/comment-page-1/#comment-2183</link>
		<dc:creator>Joe Wakefield</dc:creator>
		<pubDate>Fri, 29 Jan 2010 17:13:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.liveandcode.com/?p=271#comment-2183</guid>
		<description>I made a bit of a lame solution, but given:
1. My system doesn&#039;t need to have multiple roles per user,
2. I don&#039;t plan to ever change the role names, and
3. I&#039;m not a database normal form zealot,

it addresses my issue.

The user session &#039;create&#039; code grabs user data, runs a check on the relevant domain security groups, and saves the highest level I care about as the user&#039;s role. Whenever DA asks for &#039;role_symbols&#039;, it receives the user&#039;s role put in array form.

## xxxxxxxxxxxxxx_add_role_to_users.rb
add_column :users, :role, :string, :null =&gt; false, :default =&gt; &quot;Guest&quot;

## user_sessions_controller.rb
  def create
    @user_session = UserSession.new(params[:user_session])
    @groups = LdapUser.find(@user_session.login).groups.collect(&amp;:cn.to_sym)

    @curuser = User.find_by_login(@user_session.login)
    if @groups.include?(&quot;Inventory Admins&quot;) then
      @curuser.update_attribute(:role, &quot;admin&quot;)
    elsif @groups.include?(&quot;Inventory Users&quot;) then
      @curuser.update_attribute(:role, &quot;user&quot;)
    else
      @curuser.update_attribute(:role, &quot;guest&quot;)
    end
    
    if @user_session.save
      flash[:notice] = &quot;Login successful!&quot;    
      redirect_back_or_default account_url
    else
      render :action =&gt; :new
    end
  end

## user.rb
  def role_symbols
    [ self.role.to_sym() ]
  end</description>
		<content:encoded><![CDATA[<p>I made a bit of a lame solution, but given:<br />
1. My system doesn&#8217;t need to have multiple roles per user,<br />
2. I don&#8217;t plan to ever change the role names, and<br />
3. I&#8217;m not a database normal form zealot,</p>
<p>it addresses my issue.</p>
<p>The user session &#8216;create&#8217; code grabs user data, runs a check on the relevant domain security groups, and saves the highest level I care about as the user&#8217;s role. Whenever DA asks for &#8216;role_symbols&#8217;, it receives the user&#8217;s role put in array form.</p>
<p>## xxxxxxxxxxxxxx_add_role_to_users.rb<br />
add_column :users, :role, :string, :null =&gt; false, :default =&gt; &#8220;Guest&#8221;</p>
<p>## user_sessions_controller.rb<br />
  def create<br />
    @user_session = UserSession.new(params[:user_session])<br />
    @groups = LdapUser.find(@user_session.login).groups.collect(&amp;:cn.to_sym)</p>
<p>    @curuser = User.find_by_login(@user_session.login)<br />
    if @groups.include?(&#8220;Inventory Admins&#8221;) then<br />
      @curuser.update_attribute(:role, &#8220;admin&#8221;)<br />
    elsif @groups.include?(&#8220;Inventory Users&#8221;) then<br />
      @curuser.update_attribute(:role, &#8220;user&#8221;)<br />
    else<br />
      @curuser.update_attribute(:role, &#8220;guest&#8221;)<br />
    end</p>
<p>    if @user_session.save<br />
      flash[:notice] = &#8220;Login successful!&#8221;<br />
      redirect_back_or_default account_url<br />
    else<br />
      render :action =&gt; :new<br />
    end<br />
  end</p>
<p>## user.rb<br />
  def role_symbols<br />
    [ self.role.to_sym() ]<br />
  end</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Wakefield</title>
		<link>http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/comment-page-1/#comment-2175</link>
		<dc:creator>Joe Wakefield</dc:creator>
		<pubDate>Thu, 28 Jan 2010 20:15:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.liveandcode.com/?p=271#comment-2175</guid>
		<description>@enrico: If you are referring to &quot;@ldap_entry &#124;&#124;= LdapUser.find(self.login)&quot;, I found that only reduces the LDAP queries per page from four to two. I made a small paste running your example code to demonstrate:
http://rails.pastebin.com/m74ed7f8e

As far as I can tell, &#039;session&#039; storage is only accessible through controllers, and models can&#039;t access controller-level variables (such as current_user). Considering &quot;declarative authorization&quot; requires role_symbols in the model, I have been unable to figure out how to cache group membership properly.</description>
		<content:encoded><![CDATA[<p>@enrico: If you are referring to &#8220;@ldap_entry ||= LdapUser.find(self.login)&#8221;, I found that only reduces the LDAP queries per page from four to two. I made a small paste running your example code to demonstrate:<br />
<a href="http://rails.pastebin.com/m74ed7f8e" rel="nofollow">http://rails.pastebin.com/m74ed7f8e</a></p>
<p>As far as I can tell, &#8216;session&#8217; storage is only accessible through controllers, and models can&#8217;t access controller-level variables (such as current_user). Considering &#8220;declarative authorization&#8221; requires role_symbols in the model, I have been unable to figure out how to cache group membership properly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Enrico</title>
		<link>http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/comment-page-1/#comment-2173</link>
		<dc:creator>Enrico</dc:creator>
		<pubDate>Thu, 28 Jan 2010 16:41:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.liveandcode.com/?p=271#comment-2173</guid>
		<description>@Joe: Perhaps you could take a similar approach to the one I took for caching the LDAP entry in my previous post. That is, the first time you determine role symbols for a User, store the array in an instance variable and that way you don&#039;t have to look it up again until you build a fresh User instance for that person (which I think would happen at next login).

But there&#039;s a disadvantage to caching that information: if you accidentally gave a person a role they shouldn&#039;t have and fix that by removing them from the group, you still have to wait for that person to log out (or the session to expire) before the change will take effect. But if you have a large number of users that might be your best option.</description>
		<content:encoded><![CDATA[<p>@Joe: Perhaps you could take a similar approach to the one I took for caching the LDAP entry in my previous post. That is, the first time you determine role symbols for a User, store the array in an instance variable and that way you don&#8217;t have to look it up again until you build a fresh User instance for that person (which I think would happen at next login).</p>
<p>But there&#8217;s a disadvantage to caching that information: if you accidentally gave a person a role they shouldn&#8217;t have and fix that by removing them from the group, you still have to wait for that person to log out (or the session to expire) before the change will take effect. But if you have a large number of users that might be your best option.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Wakefield</title>
		<link>http://www.liveandcode.com/2009/12/14/ldap-based-rbac-with-activeldap-and-declarative_authorization/comment-page-1/#comment-2172</link>
		<dc:creator>Joe Wakefield</dc:creator>
		<pubDate>Thu, 28 Jan 2010 16:24:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.liveandcode.com/?p=271#comment-2172</guid>
		<description>A nice expansion to this would involve caching the user data (specifically group memberships) in the database, updated every login. Currently it queries Active Directory every time a page is loaded, and I found that it would cause a broken pipe error if I left it idle for a bit while logged in.</description>
		<content:encoded><![CDATA[<p>A nice expansion to this would involve caching the user data (specifically group memberships) in the database, updated every login. Currently it queries Active Directory every time a page is loaded, and I found that it would cause a broken pipe error if I left it idle for a bit while logged in.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
