A few conceptual questions for the experts...

[craig]

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!

 

[Nicholas Paldino [.NET/C# MVP]]

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.

 

[Joep]

1 ui dev making decision is not acceptable
2 good design => representation has nothing to do with database => different
representations are ok

 

[craig]

Craig,

See inline:

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.


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.


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]
- (e-mail address removed)

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

Thanks!

 

[craig]

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.

 

[Nicholas Paldino [.NET/C# MVP]]

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]
- (e-mail address removed)

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]
- (e-mail address removed)

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

Thanks!

 

[craig]

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]
- (e-mail address removed)

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]
- (e-mail address removed)


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

Thanks!