I am working on my first .NET development project that involves custom
role-based security per the project requirements. This lead to a general
design issue this week that really caused us some concern. I have described
the situation below because we are very curious to see what other, more
experienced, developers might suggest. The specific classes and fields are
used just to illustrate the concepts.
Our application uses role-based authorization security. Thus, we allow the
administrator to define roles to which the can define various permissions.
Permissions are defined relative to the various entities in the application,
such as Users, Customers, Services, etc. One such role might be defined as
follows:
Role: Administrator
Permissions: Add User, Delete User, View User, Update User
Thus a user that is added to the Administrator role is granted permission to
add, delete, view and update User entities. Once such a user is
authenticated, they will be authorized to perform those actions.
Now, consider that the User entity is abstracted by a User class, and
suppose that class has a Username field (among others). If an authenticated
user indicated that they would like to edit the Username field of a system
User entity, the system first checks to see what role the authenticated user
is in. If they are in an administrator role, they have the desired "Update
User" privilege described above, so the system instantiates a User object
and presents it to the user for editing. If, however, the user does not have
this permission, their request is denied and the system does not instantiate
an object.
So far, so good.
Now, suppose that another requirement is that ANY user that is logged into
the system must be granted permission to edit their own Username, regardless
of what role they are in. In otherwords, the currently authenticated user
should always be granted the ability edit their own Username.
Now, here is where we ran into a problem. If the currently authenticated
user would like to update their Username field, but they are not in an
Administrator role, the system will not allow the User object to be
instantiated, so they will not be able to edit their Username as desired.
The object that provides the functionality needed is not accessible. As we
began to think about this situation, it was not clear how best to solve the
problem and it lead to quite a bit of discussion. Naturally, we wondered if
this is a common problem for which there is a consensus solution in the
developer community, or whether there was just something inherently wrong
with our role-based security model, our object model or our logic.
Here are some of the solutions we considered. I was hoping to hear what
others think.
1. Create a hidden "System" role which has all possible permissions. Add a
hidden "System" user to this role. Anytime such a situation occurs, log out
the current user, log in the System user, perform the desired actions, then
log the current user back in.
2. Create a different class, with different security logic, that can be used
to expose the proper Username field to the currently authenticated user for
editing. This would mean that a single field in the DB would be editable
through two different classes.
3. Add additionaly security logic to the User class such that it functions
as follows: If the authenticated user requesting a User object has Update
User permission, instantiate the requesed User object. If the authenticated
user
does not have Update User permission, allow them the ability to instantiate
only the User entity that corresponds to themselves, and expose only the
Username field for editing (make all other fields read-only).
Any thoughts on the problem in general or the possible solutions? As we
thought about this situation and its possible solutions, it raised a few
other questions:
1. Is it considered good design for two different classes to both provide
read/write access to the same field in the database?
2. Does the use of a "SuperUser" account as described constitute a breech of
security?
3. Is it possible for a situation to arise in which the system might not be
able to discern the security context of a request to instantiate an object?
If so, would it be acceptable to use a parameter to communicate that
context?
Thanks!
3  2355 
Perhaps a solution - although a slightly more complex one - would be to
explictly set permissions on the user object, rather than the role. What i
mean is, in Windows, any user can belong to groups and get some permission
based on this group membership. However, you can also explicitly set a
permission on the user to say, read a file.
I'd think that in the plumbing, upon instantiation of the User (or perhaps
Identity ) object, it is assigned permissions directly. So, I pseudo-code,
on the constructor of your data class there should be something like:
public myClass() {
new DataAccessPermi ssion(DataAcces sPermission.Rea d)Demand();
// etc etc.
}
.... that permission demanding code should also be present in the properties
of your class.
What needs to be done for this though, is create your Permission sub-classes
( if an existing Permission class doesn't cover your requirements ), amd
possible implement some "plumbing" inside them to access the permission
you've set on the current user object. It's a bit tricky coding, but once
you've got it, you've a perfect case of re-use for almost any project
afterwards.
I think it's worth taking the time, actually I was planning to create that
sort of thing for the needs of my company as well in the near future,
because we're gonna re-use it in almost any project that requires security.
( This is actually a Java-driven approach, but I think the 2 frameworks are
more-or-less equivalent in functionality, so it shouldn't be very difficult
to implement without any major difficulties )
Hope this helped,
Angel
O:]
"craig" <e@mail.com> wrote in message
news:eD******** ******@TK2MSFTN GP14.phx.gbl... I am working on my first .NET development project that involves custom
role-based security per the project requirements. This lead to a general
design issue this week that really caused us some concern. I have
described the situation below because we are very curious to see what other, more
experienced, developers might suggest. The specific classes and fields are
used just to illustrate the concepts.
Our application uses role-based authorization security. Thus, we allow the
administrator to define roles to which the can define various permissions.
Permissions are defined relative to the various entities in the
application, such as Users, Customers, Services, etc. One such role might be defined as
follows:
Role: Administrator
Permissions: Add User, Delete User, View User, Update User
Thus a user that is added to the Administrator role is granted permission
to add, delete, view and update User entities. Once such a user is
authenticated, they will be authorized to perform those actions.
Now, consider that the User entity is abstracted by a User class, and
suppose that class has a Username field (among others). If an
authenticated user indicated that they would like to edit the Username field of a system
User entity, the system first checks to see what role the authenticated
user is in. If they are in an administrator role, they have the desired "Update
User" privilege described above, so the system instantiates a User object
and presents it to the user for editing. If, however, the user does not
have this permission, their request is denied and the system does not
instantiate an object.
So far, so good.
Now, suppose that another requirement is that ANY user that is logged into
the system must be granted permission to edit their own Username,
regardless of what role they are in. In otherwords, the currently authenticated user
should always be granted the ability edit their own Username.
Now, here is where we ran into a problem. If the currently authenticated
user would like to update their Username field, but they are not in an
Administrator role, the system will not allow the User object to be
instantiated, so they will not be able to edit their Username as desired.
The object that provides the functionality needed is not accessible. As we
began to think about this situation, it was not clear how best to solve
the problem and it lead to quite a bit of discussion. Naturally, we wondered
if this is a common problem for which there is a consensus solution in the
developer community, or whether there was just something inherently wrong
with our role-based security model, our object model or our logic.
Here are some of the solutions we considered. I was hoping to hear what
others think.
1. Create a hidden "System" role which has all possible permissions. Add a
hidden "System" user to this role. Anytime such a situation occurs, log
out the current user, log in the System user, perform the desired actions,
then log the current user back in.
2. Create a different class, with different security logic, that can be
used to expose the proper Username field to the currently authenticated user
for editing. This would mean that a single field in the DB would be editable
through two different classes.
3. Add additionaly security logic to the User class such that it functions
as follows: If the authenticated user requesting a User object has Update
User permission, instantiate the requesed User object. If the
authenticated user
does not have Update User permission, allow them the ability to
instantiate only the User entity that corresponds to themselves, and expose only the
Username field for editing (make all other fields read-only).
Any thoughts on the problem in general or the possible solutions? As we
thought about this situation and its possible solutions, it raised a few
other questions:
1. Is it considered good design for two different classes to both provide
read/write access to the same field in the database?
2. Does the use of a "SuperUser" account as described constitute a breech
of security?
3. Is it possible for a situation to arise in which the system might not
be able to discern the security context of a request to instantiate an
object? If so, would it be acceptable to use a parameter to communicate that
context?
Thanks!
Actually, I've just found something that might make your life much easier,
and you can combine it with the previous post:
String id1 = "Bob";
String role1 = null;
PrincipalPermis sion PrincipalPerm1 = new PrincipalPermis sion(id1, role1);
String id2 = null;
String role2 = "Supervisor ";
PrincipalPermis sion PrincipalPerm2 = new PrincipalPermis sion(id2, role2);
(PrincipalPerm1 .Union(Principa lPerm2)).Demand ();
The following code will demand that the current IPrincipal of the system is
either user "Bob", or that the current IPrincipal is a "Supervisor " ... in
that manner, you can specify that the user accessing your data class is
either an Admin, or the user with the username specified by the class
instance itself - the only disadvantage is that upon construction of the
data object, you don't really know the username contained inside the
instance you're loading without doing a "select" from the DB ... but, almost
nothing is perfect, innit ? You get some small performance overhead, but
great ease-of-use codewise
O:]
"Angelos Karantzalis" <ak**********@a giltech.gr> wrote in message
news:#K******** ******@TK2MSFTN GP14.phx.gbl... Perhaps a solution - although a slightly more complex one - would be to
explictly set permissions on the user object, rather than the role. What i
mean is, in Windows, any user can belong to groups and get some permission
based on this group membership. However, you can also explicitly set a
permission on the user to say, read a file.
I'd think that in the plumbing, upon instantiation of the User (or perhaps
Identity ) object, it is assigned permissions directly. So, I pseudo-code,
on the constructor of your data class there should be something like:
public myClass() {
new DataAccessPermi ssion(DataAcces sPermission.Rea d)Demand();
// etc etc.
}
... that permission demanding code should also be present in the
properties of your class.
What needs to be done for this though, is create your Permission sub-class
es ( if an existing Permission class doesn't cover your requirements ), amd
possible implement some "plumbing" inside them to access the permission
you've set on the current user object. It's a bit tricky coding, but once
you've got it, you've a perfect case of re-use for almost any project
afterwards.
I think it's worth taking the time, actually I was planning to create that
sort of thing for the needs of my company as well in the near future,
because we're gonna re-use it in almost any project that requires
security.
( This is actually a Java-driven approach, but I think the 2 frameworks
are more-or-less equivalent in functionality, so it shouldn't be very
difficult to implement without any major difficulties )
Hope this helped,
Angel
O:]
"craig" <e@mail.com> wrote in message
news:eD******** ******@TK2MSFTN GP14.phx.gbl... I am working on my first .NET development project that involves custom
role-based security per the project requirements. This lead to a general
design issue this week that really caused us some concern. I have described the situation below because we are very curious to see what other, more
experienced, developers might suggest. The specific classes and fields
are used just to illustrate the concepts.
Our application uses role-based authorization security. Thus, we allow
the administrator to define roles to which the can define various
permissions. Permissions are defined relative to the various entities in the
application, such as Users, Customers, Services, etc. One such role might be defined
as follows:
Role: Administrator
Permissions: Add User, Delete User, View User, Update User
Thus a user that is added to the Administrator role is granted
permission to add, delete, view and update User entities. Once such a user is
authenticated, they will be authorized to perform those actions.
Now, consider that the User entity is abstracted by a User class, and
suppose that class has a Username field (among others). If an authenticated user indicated that they would like to edit the Username field of a
system User entity, the system first checks to see what role the authenticated
user is in. If they are in an administrator role, they have the desired
"Update User" privilege described above, so the system instantiates a User
object and presents it to the user for editing. If, however, the user does not
have this permission, their request is denied and the system does not
instantiate an object.
So far, so good.
Now, suppose that another requirement is that ANY user that is logged
into the system must be granted permission to edit their own Username,
regardless of what role they are in. In otherwords, the currently authenticated
user should always be granted the ability edit their own Username.
Now, here is where we ran into a problem. If the currently authenticated
user would like to update their Username field, but they are not in an
Administrator role, the system will not allow the User object to be
instantiated, so they will not be able to edit their Username as
desired. The object that provides the functionality needed is not accessible. As
we began to think about this situation, it was not clear how best to solve
the problem and it lead to quite a bit of discussion. Naturally, we wondered
if this is a common problem for which there is a consensus solution in the
developer community, or whether there was just something inherently
wrong with our role-based security model, our object model or our logic.
Here are some of the solutions we considered. I was hoping to hear what
others think.
1. Create a hidden "System" role which has all possible permissions. Add
a hidden "System" user to this role. Anytime such a situation occurs, log
out the current user, log in the System user, perform the desired actions,
then log the current user back in.
2. Create a different class, with different security logic, that can be
used to expose the proper Username field to the currently authenticated user
for editing. This would mean that a single field in the DB would be editable
through two different classes.
3. Add additionaly security logic to the User class such that it
functions as follows: If the authenticated user requesting a User object has
Update User permission, instantiate the requesed User object. If the
authenticated user
does not have Update User permission, allow them the ability to
instantiate only the User entity that corresponds to themselves, and expose only the
Username field for editing (make all other fields read-only).
Any thoughts on the problem in general or the possible solutions? As we
thought about this situation and its possible solutions, it raised a few
other questions:
1. Is it considered good design for two different classes to both
provide read/write access to the same field in the database?
2. Does the use of a "SuperUser" account as described constitute a
breech of security?
3. Is it possible for a situation to arise in which the system might not
be able to discern the security context of a request to instantiate an
object? If so, would it be acceptable to use a parameter to communicate that
context?
Thanks!
Thanks Angelos. I really appreciate your taking the time to respond.
I will spend some time to study your posts. Looks like some good input.
"Angelos Karantzalis" <ak**********@a giltech.gr> wrote in message
news:eW******** ******@TK2MSFTN GP10.phx.gbl... Actually, I've just found something that might make your life much easier,
and you can combine it with the previous post:
String id1 = "Bob";
String role1 = null;
PrincipalPermis sion PrincipalPerm1 = new PrincipalPermis sion(id1, role1);
String id2 = null;
String role2 = "Supervisor ";
PrincipalPermis sion PrincipalPerm2 = new PrincipalPermis sion(id2, role2);
(PrincipalPerm1 .Union(Principa lPerm2)).Demand ();
The following code will demand that the current IPrincipal of the system
is
either user "Bob", or that the current IPrincipal is a "Supervisor " ... in
that manner, you can specify that the user accessing your data class is
either an Admin, or the user with the username specified by the class
instance itself - the only disadvantage is that upon construction of the
data object, you don't really know the username contained inside the
instance you're loading without doing a "select" from the DB ... but,
almost
nothing is perfect, innit ? You get some small performance overhead, but
great ease-of-use codewise
O:]
"Angelos Karantzalis" <ak**********@a giltech.gr> wrote in message
news:#K******** ******@TK2MSFTN GP14.phx.gbl... Perhaps a solution - although a slightly more complex one - would be to
explictly set permissions on the user object, rather than the role. What
i
mean is, in Windows, any user can belong to groups and get some
permission
based on this group membership. However, you can also explicitly set a
permission on the user to say, read a file.
I'd think that in the plumbing, upon instantiation of the User (or
perhaps
Identity ) object, it is assigned permissions directly. So, I
pseudo-code,
on the constructor of your data class there should be something like:
public myClass() {
new DataAccessPermi ssion(DataAcces sPermission.Rea d)Demand();
// etc etc.
}
... that permission demanding code should also be present in the
properties of your class.
What needs to be done for this though, is create your Permission
sub-class
es ( if an existing Permission class doesn't cover your requirements ), amd
possible implement some "plumbing" inside them to access the permission
you've set on the current user object. It's a bit tricky coding, but once
you've got it, you've a perfect case of re-use for almost any project
afterwards.
I think it's worth taking the time, actually I was planning to create
that
sort of thing for the needs of my company as well in the near future,
because we're gonna re-use it in almost any project that requires
security.
( This is actually a Java-driven approach, but I think the 2 frameworks
are more-or-less equivalent in functionality, so it shouldn't be very
difficult to implement without any major difficulties )
Hope this helped,
Angel
O:]
"craig" <e@mail.com> wrote in message
news:eD******** ******@TK2MSFTN GP14.phx.gbl... > I am working on my first .NET development project that involves custom
> role-based security per the project requirements. This lead to a
> general
> design issue this week that really caused us some concern. I have
described > the situation below because we are very curious to see what other, more
> experienced, developers might suggest. The specific classes and fields are > used just to illustrate the concepts.
>
> Our application uses role-based authorization security. Thus, we allow the > administrator to define roles to which the can define various permissions. > Permissions are defined relative to the various entities in the
application, > such as Users, Customers, Services, etc. One such role might be defined as > follows:
>
> Role: Administrator
> Permissions: Add User, Delete User, View User, Update User
>
> Thus a user that is added to the Administrator role is granted permission to > add, delete, view and update User entities. Once such a user is
> authenticated, they will be authorized to perform those actions.
>
> Now, consider that the User entity is abstracted by a User class, and
> suppose that class has a Username field (among others). If an
authenticated > user indicated that they would like to edit the Username field of a
system > User entity, the system first checks to see what role the authenticated
user > is in. If they are in an administrator role, they have the desired "Update > User" privilege described above, so the system instantiates a User object > and presents it to the user for editing. If, however, the user does not
have > this permission, their request is denied and the system does not
instantiate > an object.
>
> So far, so good.
>
> Now, suppose that another requirement is that ANY user that is logged into > the system must be granted permission to edit their own Username,
regardless > of what role they are in. In otherwords, the currently authenticated user > should always be granted the ability edit their own Username.
>
> Now, here is where we ran into a problem. If the currently
> authenticated
> user would like to update their Username field, but they are not in an
> Administrator role, the system will not allow the User object to be
> instantiated, so they will not be able to edit their Username as desired. > The object that provides the functionality needed is not accessible. As we > began to think about this situation, it was not clear how best to solve
the > problem and it lead to quite a bit of discussion. Naturally, we
> wondered
if > this is a common problem for which there is a consensus solution in the
> developer community, or whether there was just something inherently wrong > with our role-based security model, our object model or our logic.
>
> Here are some of the solutions we considered. I was hoping to hear what
> others think.
>
> 1. Create a hidden "System" role which has all possible permissions.
> Add a > hidden "System" user to this role. Anytime such a situation occurs, log
out > the current user, log in the System user, perform the desired actions,
then > log the current user back in.
>
> 2. Create a different class, with different security logic, that can be
used > to expose the proper Username field to the currently authenticated user
for > editing. This would mean that a single field in the DB would be
> editable
> through two different classes.
>
> 3. Add additionaly security logic to the User class such that it functions > as follows: If the authenticated user requesting a User object has Update > User permission, instantiate the requesed User object. If the
authenticated > user
> does not have Update User permission, allow them the ability to
instantiate > only the User entity that corresponds to themselves, and expose only
> the
> Username field for editing (make all other fields read-only).
>
> Any thoughts on the problem in general or the possible solutions? As we
> thought about this situation and its possible solutions, it raised a
> few
> other questions:
>
> 1. Is it considered good design for two different classes to both provide > read/write access to the same field in the database?
>
> 2. Does the use of a "SuperUser" account as described constitute a
breech of > security?
>
> 3. Is it possible for a situation to arise in which the system might
> not
be > able to discern the security context of a request to instantiate an
object? > If so, would it be acceptable to use a parameter to communicate that
> context?
>
> Thanks!
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Oxygen |
last post by:
I am a developer contracted to a large utility company. This is my
first job out of university. I have been working in IT for 2 years
now. My work involves application development, maintenance, and
support, Business Objects reporting and universe development. The DBA
where I work will not give me the DBA role in the production instance,
although I have the DBA role in the development instance. Is this
reasonable, or is he being a control...
|
by: tracy |
last post by:
hi,
just wonder, can we copy a role then add some new priviledges to the
new role.
hm.. i means, example; now i have a role named role_a. Then I copy
role_a to create role_b. After I created role_b from role_a, i would
like to revoke some privileges in role_b without affecting role_a. Can
I and how to write the script?
regards,
tracy
|
by: Ted |
last post by:
How do I grant all privileges for a schema that has a large number of
existing tables, procedures, functions, etc to a newly created role,
without having to issue a grant statement for each object and each
privilege? I want the role to have all of the rights of the schema
owner.
Is there any kind of blanket granting of all privileges to a role?
|
by: gudia |
last post by:
How would I, using a sql script, copy permissions assigned to a user
or a role in one or more databases to another user or a role in their
respective databases?
Help appreciated
|
by: Mark White |
last post by:
Hey everyone
I'm having a great deal of problems finding this information through google
and yahoo, so I turn to you on this.
I have a Windows app running on XP. I am able to caputre the user's Name
property in the WindowsPrincipal's IIdentity interface.
Where can I find the role that the user is assigned for the current login?
I only want the one role which is assigned for the current user, not all of
| | |
by: Louly |
last post by:
Hi everybody,
I'm a 22 yrs old girl. I've been developing a Database for 6 months no
using Access. A week ago I had this feeling that I'm wasting my time
in Access. I don't think it's wise to keep on working with Access.
Instead I think I should consider learning and being a certified Oracle
proffessional or something. What do you guys think?
Thanks for your help.
Miriam
|
by: ferherra |
last post by:
Hi,
Hope someone can help...
I databind my gridview (asp.net 2.0) like this:
GridView1.DataSource = Membership.GetAllUsers();
(MembershipUserCollection)
GridView1.DataBind();
In the GridView1_RowDataBound eventhandler
I'm getting the user role for each user (each user will only have and
|
by: CK |
last post by:
Does anyone have any experience with this? We have an exisitng sql database
with user and role info. I need to write a custom role provider to use this
data. Does anyone have any examples of this being done? I have googled it
and I see on MSDN an XMLReadOnlyRoleProvider. I need something similiar to
this. When writing a custom role provider, does the developer write the
ADO.NET code in the methods to retrieve the user and role info? My only...
|
by: cybertoast |
last post by:
i seem to have some misunderstanding about how roles work in sql server
2005. i see that i can add a role to a database
(dbname->->properties->permissions->. THis allows
me to add either users or roles. Users can be added programmatically
using sp_grantdbaccess @username, but this does not allow for addition
of roles to access the database (i.e., sp_grantdbaccess @rolename does
not work).
Is there some other command that is used to add...
|
by: monty |
last post by:
Hi All,
I am facing a problem while executing a statement through C++ code
using OLEDB API of Sql server.
There is a problem with DB_OWNER role. If I will enable the DB_OWNER
everything is going fine but if I will remove this role than I am
getting error "DB_E_ERRORSINCOMMAND".
But if I will execute the same in query analyser it is going
absolutely fine in either case.
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
