NYCPHP Meetup

[csnyder]

On 8/26/07, Cliff Hirsch <cliff at pinestream.com> wrote:
>
> I was waiting for you to chime in here. Just re-read your RBAC chapter in Pro
> PHP Security (AWESOME BOOK, BTW). Nice Hamptons beach reading. Its that or
> Clive Cussler.
>
> As I think about this, the problem is all the "locations". A front-end
> controller can consolidate or automatically synthesize and manage locations.
> But there could be soooo many. And it seems to me the presentation layer needs
> a heck of a lot of if statements to hide sections, links, buttons, etc. if you
> want to hide unaccessible stuff instead of a simple "not authorized" msg.

That depends on your information architecture (how interconnected is
everything, really?) and how granular your access policies are. But
it's true what you say--there's a _lot_ of checking to see if the user
can do this or access that in any reasonably complex system.

I just looked at a typical calendar view and counted around 360
separate access control checks. It's extremely important that these
checks be as inexpensive as possible--you obviously don't want to hit
the database or ldap directory that many times.

But that doesn't mean you have to write a bunch of conditional
statements. Access control is, ideally, itegrated into your framework.
When you fetch a collection of objects to populate a navigation menu,
the ones that the user doesn't have access to shouldn't be sent to the
presentation layer in the first place.

That "embeddedness" is the main reason why we didn't include an actual
RBAC system in Pro PHP Security--the sample code would have had to
implement an entire mini framework.

-- 
Chris Snyder
http://chxo.com/