Re: A few conceptual questions for the experts...
From: Nicholas Paldino [.NET/C# MVP] (mvp_at_spam.guard.caspershouse.com)
Date: 10/19/04
- Next message: Fernando Rodríguez: "Downcasting objects in an ArrayList"
- Previous message: Joep: "Re: A few conceptual questions for the experts..."
- In reply to: craig: "A few conceptual questions for the experts..."
- Next in thread: craig: "Re: A few conceptual questions for the experts..."
- Reply: craig: "Re: A few conceptual questions for the experts..."
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 19 Oct 2004 11:39:58 -0400
Craig,
See inline:
>
> 1. Assume you are developing an application which incoporates a
> role-based security model. An administrator can define roles with
> specific privileges and then add users to those roles. After a user has
> been authenticated, their role information is retrieved which then
> determines what privileges thay have. My question is this: would it be
> considered a violation of security if these privileges were not enforced
> by the middle-tier components? In other words, in a windows forms
> application, would it be acceptable to allow the UI developer to make
> decisions about what data can be exposed to the user based upon the user's
> role information, or does this need to be enforced at the component level?
You can do it at both, but at the least, you must do it at the middle
tier. This way, the security restrictions flow to any client that you have.
Generally, your middle tier should do all the work, with nothing being left
to the UI. This way, security is integrated correctly into your app. All
your app has to do is say "Hey, I'm this person and I want to do this". The
UI shouldn't try and tell it whether it can or can not, but rather, relay
the message from the components that do the work. The UI just facilitates
this operation.
>
> 2. How important would you say that it is that specific fields within the
> DB can be exposed to the user through more than one type of class? For
> example, a user password field could be exposed to an administrator
> through a "User" object which is used to configure system users (the
> "User" object could have a password field). However, because only users
> in administrative roles would have the privilege of modifying this field,
> users that do not have administrative privileges would not be able to use
> this object to modify their own password. Thus, this field must also be
> exposed using a different class for which any authenticated user would
> always have modification privileges, such as a "Password" class. Thus, we
> end up with to different classes, "User" and "Password" which both allow a
> user to modify the same password field in the DB. Is this considered good
> design? Would it be considered bad design to restrict all DB fields to
> being accessed by only a single class?
I think this is a bad design. What I would do is have logic on the
validation for the user object which would check to see if the role that is
changing the password is the administrator role. Of course, you could
whittle this down to another method which specifically changes the password,
and restrict that to only the Administrator role. Then, deny all other
attempts to change the field anywhere else.
> If we were to restrict all fields to being access by a single class, we
> would then be forced to override system security at times in order to
> access a field for which the logged in user does not have privileges (as
> in the case of a password, as described above).
Why would you be forced to override security? If you are using
EnterpriseServices, or an IPrincipal implementation, you can find the roles
that the user belongs to easily, and then just check in your object if the
user is in the appropriate role. If they are not, then disallow the change,
otherwise, allow it. This way, only administrators can change it, and you
don't fragment your code.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
>
> I would be very interested in the opinions of others who have encountered
> these types of issues.
>
> Thanks!
>
- Next message: Fernando Rodríguez: "Downcasting objects in an ArrayList"
- Previous message: Joep: "Re: A few conceptual questions for the experts..."
- In reply to: craig: "A few conceptual questions for the experts..."
- Next in thread: craig: "Re: A few conceptual questions for the experts..."
- Reply: craig: "Re: A few conceptual questions for the experts..."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|