I've reread the appropriate sections regarding IIdentity and IPrincipal in Rocky's book, but I'm still having a problem trying to use custom authorization with Windows authentication in a WinForms project.
My client is wanting to dispense with having to key in a username/password combination to access the application I'm creating for them, so I'll be authenticating users via either Active Directory or Windows authentication. Due to granularity issues, I'm including a HasPermissions method, which acts similar to the IsInRole method, in a custom principal class based on the BusinessPrincipalBase. The problem I'm encountering is in trying to derive a custom identity from the WindowsIdentity object suitable for use in calling the HasPermissions method. Any ideas?
I thought I'd clarify my original post somewhat. I'm not having problems getting the custom principal as my Login routine includes the following section of code just prior to returning windowsIdentity.IsAuthenticated to the caller:
if (windowsIdentity.IsAuthenticated)
{
CustomPrincipal principal = new CustomPrincipal(windowsIdentity);
Csla.ApplicationContext.User = principal;
}
The real problem lies in trying to obtain a CustomIdentity for the user inside the HasPermissions method; said method being used to check whether someone is in a particular role for a particular department. A department manager in a department can add/delete/update items at the departmental level, whereas someone in the same department with less authority is only able to read departmental items. IsInRole would work perfectly if that was all there was to it. The fly in the ointment is that a department manager may be called on to lend assistance to another department as, say, an estimator; in such a case, the user shouldn't be allowed to do anything other than read departmental items. I need to be able to make a call similar to HasPermissions("Architectural", "DeptMgr") to see if the user is the department manager for the Architectural department. I'm not having any problems at all if I use custom authentication and authorization, in which HasPermissions is defined as:
public bool HasPermissions(string department, string role)
{
CustomIdentity identity = (CustomIdentity)this.Identity;
return HasPermissions(department, role);
}
BTW, the client isn't sure yet whether or not they're going to implement AD; it's one of several things they're looking at doing sometime in the future.
I've taken our's to a bit more hybrid approach.
I authenticate to the network then use a custom build for responsibilities within the application. I needed multiple levels of access so that we could build an audit trail that would satisfy quality standards for team involvement and authorization of specialized work. Basically, it it requires a Chemist, a lab tech can't sign off.
It has worked well, though I think in .NET 2.0 with CSLA 2.x it would work a hell of a lot better. Right now I've got a Frankenstein CSLA 1.53 with enhancements from CSLA 2.0 to help fill the gaps for field level authorization.
I anticipate users thinking it's too restrictive to make people who are supposed to do something do their job, so it'll allow anyone on the team to authorize and it logs who, what when and why. It has passed two internal TS16949 audits, an internal AS9100 and I'm getting a DOD review soon from our "internal spooks".
_E
Copyright (c) Marimer LLC