views:

1085

answers:

3

Can anyone briefly explain what is the use of GenericIdentity and where to use it.

A: 

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.

Alex Martelli
A: 

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.

Cesar
+7  A: 

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

Marc Gravell
How does the PrincipalPermission attribute work? Will an exception be raised if Thread.CurrentPrincipal doesn't contain the correct role when the method is called or something?
Svish
@Svish - exactly (`SecurityException`); it is one of the (few) attributes that the runtime acts on directly.
Marc Gravell