I'm implementing role based security using Microsoft's membership and role provider.
The theoretical problem I'm having is that you implement a specific role on a method such as:
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
private void someMethod() {}
What if at some point down the road, I don't want Supervisors to access someMethod() anymore?
Wouldn't I have to change the source code to make that change? Am I missing something?
It seems there has to be some way to abstract the relationship between the supervisors role and the method so I can create a way in the application to change this coupling of role permission to method.
Any insight or direction would be appreciated. Thank you.
If you use the declarative approach, then yes - if you suddenly don't want members of the Supervisor to be able to call your method, you need to change your source code for that.
You can, however, also do all of this in code, programmatically:
private void someMethod()
{
WindowsPrincipal currentUser = (Thread.CurrentPrincipal as WindowsPrincipal);
if (currentUser != null)
{
if (currentUser.IsInRole("Supervisor"))
{
// do something here
}
}
}
You can always get the current Windows principal your Winforms app is running under, and then you can call the IsInRole method to check whether or not a given user is in a given role. Of course, you can also make all of this configurable, e.g. read the required role from a config file, and if you want to allow everyone in, you just simply change the role to be Users or something
PrincipalPermissionAttribute does not tend to be used in many applications I've worked on for the reason you've touched upon; the attribute applies a policy which can only be altered by a code change.
The alternative is to use the PrincipalPermission class directly. All security attributes resolve to similarly named classes and method calls at run time. In the case of your attribute, the following code is executed:
PrincipalPermission permission = new PrincipalPermission(null, "Supervisor");
permission.Demand(); // Throws SecurityException if user is not in the role.
If you use the permission classes directly, you gain more control over how your permissions are formed. You could have a database which you query to get a list of roles and perform a demand for them like this:
private void someMethod()
{
IEnumerable<string> roles = GetRolesForMethod("someMethod");
PrincipalPermission permission = null;
foreach(string role in roles)
{
if(permission == null)
{
permission = new PrincipalPermission(null, role);
}
else
{
permission = permission.Union(
new PrincipalPermission(null, role);
);
}
}
if(permission != null)
{
permission.Demand();
}
}
Related
Is there a way to control access to methods to certain roles in .net. Like
class A
{
//should only be called by Admins**
public void Method1() { }
//should only be called by Admins and PM's**
public void Method2() { }
}
I'm using windows authentication only for retrieving user names and nothing more.User roles are maintained in a different application. I think it's possible through attributes but I'm not really sure how
It it possible, I have used it on an web project that used asp.net and AzMan as the authentication.
Take a look at Code Access Security
From memory all of our methods looked something like
[Permission(SecurityAction.Demand, "Permission")]
public void Method1
It's been a while though so that might not be actually 100% correct.
I'd also highly suggest if you are going to put protection down to this level to look at a task orientated permission approach as this is much more flexible than role based permissions
You can do this as follows:
class A
{
//should only be called by Admins**
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
public void Method1()
{
}
//should only be called by Admins and PM's**
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
[PrincipalPermission(SecurityAction.Demand, Role="PM")]
public void Method2()
{
}
}
To do this Thread.CurrentPrincipal must be set to a principal that has the required roles. For example, if you enable roleManager in an ASP.NET application, Thread.CurrentPrincipal will be set to a RolePrincipal with roles from your configured RoleProvider. See this MSDN article for more info.
You can do it using custom validation.
1- Make a method in another public class which take login id as parameter and return roles in form of bits.
2- Call this method on the page_Load event of the required class and save returned bits in the view state.
3- Now validate required method on the basis of roles bits.
Is there an easy way to substitute current User object (the one inside controller) with IPrincipal having properties of another user? I'm thinking about environment that users Windows authentication and AD groups, so it's desirable to replicate all AD properties.
The "hard" way is to do LDAP query and implement IPrincipal interface, but I want to avoid that.
I solved this by adding a property like this to my base controller:
new public IPrincipal User
{ //we override User for impersonation
get {
if (/*check for impersonation*/)
{
return /*impersonated*/;
}
else
{
return base.User;
}
}
}
Create an interface/class to wrap the access to the current user object. Your custom service can return the user object or whatever you would like, and it will be easy to mock up in tests.
I have a Delete method on all my business objects that has the PrincipalPermission attribute on it.
Example:
[PrincipalPermission(SecurityAction.Demand, Role = "Vendor Manager")]
public static bool Delete(Vendor myVendor)
{
//do work here
}
The problem is that it appears to be completely ignoring my PrincipalPermission. It lets anyone through, no matter what role they may be part of.
Is there something else I've forgotten to do? I have added the following to my Application's global.asax in the Application Startup section:
AppDomain.CurrentDomain.SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal);
But that doesn't make any difference either.
I also just tried the following:
public static bool Delete(Vendor myVendor)
{
PrincipalPermission iPerm = new PrincipalPermission(null, "Vendor Manager");
iPerm.Demand();
//do work here
}
and wouldn't ya know, this works just fine!.... any ideas on why it works one way but not the other?
Did you get an answer for this? I just tested this in my own application and it works pretty well. I'm specifically NOT adding
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
And, I'm using Forms Authentication (ASP.NET Membership), MVC 2, .NET 3.5.
I did however discover if I decorate my class with the following my method decorations do not work.
[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
Only one observation for any people that says that sample does not work. Check the name for the role according with your local culture. For example, if you resides in Mexico, you must to use: #"BUILTIN\Administradores" instead of #"BUILTIN\Administrators".
Have you validated that the Windows principal doesn't happen to have the permission you're requiring? Something like this (modified from here) -- I would think -- should mimic that behavior and allow you to step through. It should indicate whether or not the permission is granted.
If this passes, then I would expect the attribute to pass on through as well. If this fails, but the attribute passes through, then I'm as stumped as you are.
static void Main(string[] args)
{
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
PrincipalPermission principalPerm = new PrincipalPermission(null, "Vendor Manager");
try
{
principalPerm.Demand();
Console.WriteLine("Demand succeeded.");
}
catch (Exception secEx)
{
Console.WriteLine("Demand failed.");
}
Console.ReadLine();
}
I was wondering if anyone would be able to help me with the following?
I need some more complicated rules for authorisation in a webapp than just role, which I have working fine. Something along the lines of "Allow all Admins. Allow Buyers, provided they have the correct department ID and are allowed to see this customer's credentials".
I am using a custom identity and custom principal to store information such as whether a user is allowed to see all clients or which individual clients they may see. This information is retrieved from a database and added upon creation of the identity/principal.
I have created a custom permission that extends IPermission, ISecurityEncodable. Within this, I have modified the Demand() function to the following:
public void Demand()
{
this._identity = (UserIdentity)Thread.CurrentPrincipal.Identity;
if (Thread.CurrentPrincipal.IsInRole("Admin")) { }
else if ((Thread.CurrentPrincipal.IsInRole("Buyer")) &&
(this._identity.CanViewAllClients) &&
(this._identity.IsInDept(this._departmentID)) ) { }
else if ((Thread.CurrentPrincipal.IsInRole("Buyer")) &&
(this._identity.CanViewClient(this._requestedClient)) &&
(this._identity.IsInDept(this._departmentID)) ) { }
else { throw new SecurityException("Custom Permission Denied"); }
}
I then call this when I wish to authorise by using
CustomPermission custperm = new CustomPermission(requestedClient, reqClientDept);
custperm.Demand();
This works fine, but seems a messy, hacky way to do things. Especially since it would be nice to use my security roles as an attribute e.g.
[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public class...
Perhaps there is a way to call [CustomPrincipalPermission(SecurityAction.Demand, Authorised = true)] with a custom IsAuthorised check? Is this possible? What would need to be implemented?
I apologise if there is a simple solution that I've missed online, but rest assured I have been checking for days now.
It seems like what you want is a declarative rather than a programmatic demand. In order to do so, you'll need to create a CustomPermissionAttribute based on your CustomPermission.
There's an example of a declarative demand of a custom permission here and details of creating a custom permission attribute here.
Can anyone briefly explain what is the use of GenericIdentity and where to use it.
GenericIdentity and GenericPrincipal are the simplest way of describing a user as a "principal". This can be used for implementation-unaware security checking in an application - i.e. if the user logs in as "Fred" with the "User" and "Admin" permissions:
string[] roles = { "User", "Admin" };
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Fred"), roles);
You might do this at the point of client login to a winform, or there are specific points to do this in WCF, ASP.NET, etc.
Then later code, without having to know how those permissions are handled, can check that permission - either via IsInRole, or declaratively:
[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
void SomeAdminFunction() { }
Some useful utility code here is null-safe wrappers around principal/identity:
public static string GetUsername() {
IPrincipal principal = Thread.CurrentPrincipal;
IIdentity identity = principal == null ? null : principal.Identity;
return identity == null ? null : identity.Name;
}
public static bool IsInRole(string role) {
IPrincipal principal = Thread.CurrentPrincipal;
return principal == null ? false : principal.IsInRole(role);
}
Then you might have some audit code in your DAL:
row.UpdatedBy = MyUtilityClass.GetUsername();
GenericPrincipal is useful for the simple cases of a plain username and set of known roles.
More sophisticated principal implementations might, for example, do "on demand" access checking - i.e. until you ask for the "Foo" role it doesn't know - it then finds out (by talking to a web-service, database, active-directory, etc) and caches the result for future access. This is useful when the list of potential roles is large, and the number of roles typically queried in reality is small.
You can also use a principal to store extra identity information that is only needed in certain contexts - for example, a security token. Callers might test the principal with as to see if it supports the extra data.
Using "principal" is useful because your logic processing code can talk about identity, without having to know whether this is winforms, ASP.NET, WCF, a windows service, etc - it is abstract. Additionally, some 3rd party code will also talk to the principal.
As another example - I wrote some example code here that shows how to use the principal to control access to winform controls via the designer (via an IExtenderProvider - which puts extra entries into the property grid in VS).
You can use GenericIdentity as a concrete implementation of Identity where you want to supply the details yourself, programmatically, about the current user. Pretty good if you have identified and authenticated the user yourself, through other channels.
GenericIdentity class can be used in conjunction with the GenericPrincipal class to create an authorization scheme that exists independent of a Windows domain.
GenericIdentity myIdentity = new GenericIdentity("MyUser");
Check out
http://msdn.microsoft.com/en-us/library/system.security.principal.genericidentity.aspx
You will find some examples up there. It represents a generic user.
Authentication and profile perissions.
GenericIdentity Class:-
The GenericIdentity class implements the IIdentity interface. It represents the identity of the user based on a custom authentication method defined by the application.
GenericPrincipal class:-
The GenericPrincipal class implements the IPrincipal interface. It represents users and roles that exist independent of Windows users and their roles. Essentially, the generic principal is a simple solution for application authentication and authorization.