Sorry mistook you for a more general discussion on client middle Tier
security.
In nearly all cases I simply return an access code in a user class when
the user logs in .
This has an int with bits for varies systems. I use an enumeration for
this ie enum Rights {Account_Rights , Account_Admin_Rights ...) ;
The UI can then hide the buttons , as it is more UI logic than business
( ie not display the buttons) I would just put the conditions direct in
the form. If the user has no rights to middle tier then he can not
logon , so only system users can login .
The only real flaw is someone internal can hack the DB or middle Tier
direct, with the information from earlier packets but this is painful to
avoid (which is what I was sort of getting at in my last email ).
Regards,
Ben
> -----Original Message-----
> From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Roni Burd
> Sent: Monday, 10 January 2005 11:59 AM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Architecture question on security and
> permissions
>
> In my case I'm starting a project form scratch, so I have no legacy
system
> to deal with.
>
> What I was asking are solutions in both enterprise internal and client
> code.
> Let me give a few examples:
>
> Imagine a WinForm app where you have CRUD operations for Clients.
> Depending
> on how the user logged in, he will be able to see the Save or Update
menu
> or
> button. My thinking was having an interface or implementing
> IExtenderProvider on all the controls or menus to show them or not.
>
> Also for security reasons, a way to ensure that BLL.Clients.Update()
can
> be
> executed by a user or not.
>
> So what are you're experience?
>
>
> -----Mensaje original-----
> De: Unmoderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] En nombre de Ben
Kloosterman
> Enviado el: Sunday, January 09, 2005 7:35 PM
> Para: [email protected]
> Asunto: Re: [ADVANCED-DOTNET] Architecture question on security and
> permissions
>
> Depends what you are talking about
>
> Enterprise internal , client connected systems or internal .
>
> I find in most cases most developers and admin guys don't understand
and
> stumble through even basic security policies and productivity breaks
> down. You also have to remember in most enterprises you still have
> clear passwords going across the wire in a lot of UNIX/ legacy
systems.
> In most organisations anything else is pointless until these and ,
weak
> passwords and dbo / admin accounts on databases are fixed.
>
> The web site and client connectivity is a different kettle of fish.
> Though current practices are adequate.
>
> Getting into detailed .Net security is beyond the need of most
> organisations, why fix a small pipe when the dam is already open. In
> most cases if you get the basics right across your organisation you
are
> in a better position than trying more complex ones.
>
>
> Ben
>
> > -----Original Message-----
> > From: Unmoderated discussion of advanced .NET topics.
> [mailto:ADVANCED-
> > [EMAIL PROTECTED] On Behalf Of Roni Burd
> > Sent: Saturday, 8 January 2005 11:26 AM
> > To: [email protected]
> > Subject: [ADVANCED-DOTNET] Architecture question on security and
> > permissions
> >
> > Hi, I'm in research fase of a modest size enterprise application.
I've
> > programmed a lot with .NET before but was never quite satisfied with
> the
> > way
> > we were dealing with security and permissions and I wanted to ask
you
> guys
> > for your experience. So here go some questions hoping to start an
> > interesting thread.
> >
> >
> >
> > I've been reading about class access and method access security
using
> > "Security Demand", "Security Override" and "Security Optimization".
> How
> > good
> > are these methods and how painfull it is to implements them across
my
> BLL
> > and DAL.
> >
> >
> >
> > Also I've been wondering for a long time how people manage the UI.
Is
> > there
> > a way of decorating controls (maybe IExtenderProvider) so they can
> disable
> > themselves when the user is not allowed to view them, or maybe
> disable.
> > Think menus, buttons, hidden fields, etc.
> >
> >
> >
> > Finally how does Authorization and Profile Application Block fits
into
> the
> > picture and what experience you have using it (tips, things to be
> careful
> > of, etc)
> >
> >
> >
> > As you can tell, I'm really newbie when it comes to .NET security
> using
> > functionalities that are provided in the framework. Also I haven't
> been
> > able
> > to find articles describing security these features.
> >
> >
> > ===================================
> > This list is hosted by DevelopMentor(r) http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor. http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
===================================
This list is hosted by DevelopMentor� http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
