473,326 Members | 2,061 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

A few conceptual questions for the experts...

I have two questions that aren't necessarily C#-related, but I think there
are many people in this forum who have some insight into these concepts, so
I thought I would ask anyway:

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?

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?

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).

I would be very interested in the opinions of others who have encountered
these types of issues.

Thanks!
Nov 16 '05 #1
6 1159
1 ui dev making decision is not acceptable
2 good design => representation has nothing to do with database => different
representations are ok
Nov 16 '05 #2
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]
- mv*@spam.guard.caspershouse.com

I would be very interested in the opinions of others who have encountered
these types of issues.

Thanks!

Nov 16 '05 #3

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uk**************@tk2msftngp13.phx.gbl...
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.


Well, I suggested using multiple representations of the same data as
follows:

1. User class, with a Password field (only accessible to users in an
administrator role)
2. Password class, with a Password field (accessible to any currently
authenticated user)

You seemed to suggest that this was a bad design. However, if I were to use
only a single representation of the DB password field, as in the User class,
there would be no way for the currently logged in user to access this data
unless that user was in an administrative role.

Therefore, is an authenticated user who was not in an administrator role
wanted to change their own password, the component would be forced to ignore
security and retrieve the User object for this user anyway, allowing them to
modify its Password field and then resaving it.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

I would be very interested in the opinions of others who have encountered
these types of issues.

Thanks!


Nov 16 '05 #4

"Joep" <St***@DeStoep.nl> wrote in message
news:41***********************@news.xs4all.nl...
1 ui dev making decision is not acceptable
2 good design => representation has nothing to do with database =>
different representations are ok


Thanks Joe,

Let me ask you this.....if different representations are ok as you have
suggested, this would imply that a single DB field could be modified in the
context of different classes (such as the password field in the two classes
of my example: the User class and the Password class).

If that is the case, how might this affect the history records that are
maintained for eith of these representations? In other words, if a user
changes a password using the password object, should a new history record
for the User object be created because one of its member fields has been
modified (though, in a different context)? Its an interesting problem.
Nov 16 '05 #5
Craig,

I kind of have to ask why you are storing passwords at all? If
anything, you should be storing hashes, at the least.

I wouldn't even bother exposing the Password property (this is bad
design from the security perspective), and offer everything else through
your object. To set the password, I would have a method on an object which
all it does is set the password for a particular user. You don't
necessarily need it attached to the User object (personally, I think that
attaching business functionality to data containers is a bad idea in the
enterprise space, rather, you should have a class that has the operations on
the data container, and then performs the actions).

This way, all you have to do is administer the role on the method that
sets the password.

If you must expose the password somehow, then have a separate method
which would provide the password, which is also subject to access control.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
Well, I suggested using multiple representations of the same data as
follows:

1. User class, with a Password field (only accessible to users in an
administrator role) 2. Password class, with a Password field
(accessible to any currently authenticated user)

You seemed to suggest that this was a bad design. However, if I were to
use only a single representation of the DB password field, as in the User
class, there would be no way for the currently logged in user to access
this data unless that user was in an administrative role.

Therefore, is an authenticated user who was not in an administrator role
wanted to change their own password, the component would be forced to
ignore security and retrieve the User object for this user anyway,
allowing them to modify its Password field and then resaving it.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

I would be very interested in the opinions of others who have
encountered these types of issues.

Thanks!



Nov 16 '05 #6

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eb**************@TK2MSFTNGP10.phx.gbl...
Craig,

I kind of have to ask why you are storing passwords at all? If
anything, you should be storing hashes, at the least.

I agree. I was just using this as an example to illustrate the problem.
I wouldn't even bother exposing the Password property (this is bad
design from the security perspective), and offer everything else through
your object. To set the password, I would have a method on an object
which all it does is set the password for a particular user. You don't
necessarily need it attached to the User object (personally, I think that
attaching business functionality to data containers is a bad idea in the
enterprise space, rather, you should have a class that has the operations
on the data container, and then performs the actions).

Sounds like you are decsribing a more data-centric architecture than we are
using. We are using Rocky Lhotka's CSLA Framework which is based upon
intelligent objects rather than data containers. Rocky makes the case in
his book "Visual Basic .NET Business Objects" for smart objects rather than
data containers.
This way, all you have to do is administer the role on the method that
sets the password.

If you must expose the password somehow, then have a separate method
which would provide the password, which is also subject to access control.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
Well, I suggested using multiple representations of the same data as
follows:

1. User class, with a Password field (only accessible to users in an
administrator role) 2. Password class, with a Password field
(accessible to any currently authenticated user)

You seemed to suggest that this was a bad design. However, if I were to
use only a single representation of the DB password field, as in the User
class, there would be no way for the currently logged in user to access
this data unless that user was in an administrative role.

Therefore, is an authenticated user who was not in an administrator role
wanted to change their own password, the component would be forced to
ignore security and retrieve the User object for this user anyway,
allowing them to modify its Password field and then resaving it.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
I would be very interested in the opinions of others who have
encountered these types of issues.

Thanks!



Nov 16 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Boris Ammerlaan | last post by:
This notice is posted about every week. I'll endeavor to use the same subject line so that those of you who have seen it can kill-file the subject; additionally, Supersedes: headers are used to...
4
by: Daniel Ladd | last post by:
Hi, I have a problem with a conceptual graph in c++. I have a oist of structures like this: typedef struct Conceptual { char* Name;//Rappresenta la parola da mettere nel grafo Conceptual* Next;...
53
by: ROSY | last post by:
hello, response if u ,on all level of questions::: 1.how a self deletable .exe file deleted on some future date & time without invoking the .exe itself? 2.if we want that any wildcard...
2
by: jason | last post by:
Please pardon my completely lack of understanding on the topic. I have a website I developed with another developer. We are both far from experts in VB.NET and OOP. We developed the site WITHOUT...
4
by: MrHelpMe | last post by:
Hello experts, Using asp with javascript and after reading many articles I found that 1 way to hide url is to use frames. However, my application has a form in which the user enter's values and...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.