I agree with you, this could become quite complex. What if you would use
the System.Security.Principal security Principle object and do something
like this:
String[]arrRoles = {"Administrator", "User"};
GenericPrincipal objPrincipal = new GenericPrincipal(new
GenericIdentity("AppUser"), arrRoles);
Thread.CurrentPrincipal = objPrincipal;
And have the business object check the IsInRole method of the current
principal, and have it raise an error if a user tries to do something he
isn't allowed to do. You could use declarative security using attributes
as well, like this:
[PrincipalPermissionAttribute(Security.Demand, Name="AppUser",
Role="Administrator")]
MyMethod()
{
...
}
Hope this helps a bit...
Nikander Bruggeman
-----Oorspronkelijk bericht-----
Van: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Namens Roni Burd
Verzonden: maandag 10 januari 2005 13:59
Aan: [email protected]
Onderwerp: Re: [ADVANCED-DOTNET] Architecture question on security and
permissions
You said "I would just put the conditions direct in
the form."
In my previous project this was a pain to implement so hence one of my
questions. I used to have a form showing a list of all Clients and then
a form with edit functionalities. The issue was that in order to edit or
delete certain clients you had to had certain security attributes that
related to other business rules, per example, if the user was the Store
Manager or Company Admin. So the logic of allowing the user to edit or
delete was based on the client and other complex rules that made more
sense as a Business rule rather than strict UI logic.
I was unable to find a satisfactory solution so ended up doing what you
propose but found myself very quickly having a complex "if then if" for
all the special roles.
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ben
Kloosterman
Sent: Sunday, January 09, 2005 10:37 PM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Architecture question on security and
permissions
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
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
Disclaimer:
This message contains information that may be privileged or confidential and is
the property of Sogeti Nederland B.V. or its Group members. It is intended only
for the person to whom it is addressed. If you are not the intended recipient,
you are not authorized to read, print, retain, copy, disseminate, distribute,
or use this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
===================================
This list is hosted by DevelopMentor� http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
