It's really not tedious at all. All permissions are assigned to roles. Which there are only a few per application. So thats really all you have to manage aside from assigning roles to the users.

-adam

> -----Original Message-----
> From: Tangorre, Michael [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 03:12 PM
> To: 'CF-Talk'
> Subject: RE: Securing CF Apps.
>
>  
> > First Union's (now Wachovia) site.
> > However, they could have eliminated that with cferror.
>
> Chevy Chase is JSP and has since corrected the error, but damn, what a
> blatant oversight.
>
> > Say you are using Oracle. Rather than build your own user
> > tables for each database, you can use Oracles built in user
> > system. There are a number of benefits, such as creating
> > profiles for password standards and account expiration and
> > lockouts. IMO the best part is the security. You create an
> > oracle user for each user of your application, then you
> > assign them oracle roles for you application. So now oracle
> > handles your applications users and roles. Then you can lock
> > down each role with permissions. Say you have a view_only
> > role. That role will only be assigned permission to SELECT on
> > tables. I can get much more grandular that too, but I think
> > you can get the idea.
>
> I'm with you and understand the concept in theory but maintainig hundreds,
> possibly thousands of accounts would be tedious! I have been using a
> roles/permissions based security architecture with great success so far, and
> the administrative app to control it for any application is plug and play
> with FB4... Just drop in the 3 circuits (MVC) and I now have a fully tested
> and functional security framework.... Needing to be populated of course.
>  
> > Additionally, everything should be in stored procedures.
>
> Totally agree with you here.
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to