|
|
|
Community Member
|
|
This is my first post in PostSharp so please bear with me.
I always thought of Application security as one of the non-functional parts (though an
important part ofcourse) of the application.
Building complex financial or medical applications is hard-enough and maintainability is always a big concern as change to code has to be accommodated at regular pace and at different times of the application's life-cycle (extending upto 7 years or more)
I always wanted to some-how "isolate" auditing/exception/security code from the functional code so developers maintaining the code only need to bother with the functional-requirement at hand.
PostSharp looks so natural fitting for "injecting" exception/auditing capabilities into the code to achieve its goal of cutting-down on repeated code.
Building authorization/permission security in the same manner is what I can't get my head around.
Permissions are usually tied to a Page (screen), Report, or Menu-Item (I handle other objects like page controls differently similar to <!-- m --><a class="postlink" href="http://www.simple-talk.com/dotnet/windows-forms/controls-based-security-in-a-windows-forms-application/">http://www.simple-talk.com/dotnet/windo ... plication/</a><!-- m -->)
A Page(screen)/Report could be opened by a menu-item and/or some button(s) that reside in one or more other Pages(screens).
When a user logon to the application, all menu-items and buttons that open a Page/Report he does not have permissions for; these menu-items/buttons should be Disabled or Hidden
So to use PostSharp for this:
1- build a custom attribute(s) but which one(s) is/are the best suited to extend?
2- Tag the main-menu control and every page (screen) with a custom PostSharp attribute
3- Handle RuntimeInitialize as then I would have the user's permissions
I was hoping if anyone has tried to implement similar architecture using PostSharp as I cannot quite figure-out how to solve the issue of discoverability (for the MenuAttribute knowing which screen/report a menu-item opens; and for the FormAttribute knowing if any of its controls opens a Form/Report and what Form/Report that control opens)
I am really excited about PostSharp as an impressive piece of software that does its magic so simply that would drive many developers I know to AOP with open arms <!-- s:) -->  <!-- s:) -->
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Hi Omar,
Thank you for sharing your thoughts.
I think you can achieve authorization quite easily just by implement OnMethodBoundaryAspect.OnEntry. On PostSharp 2.0, it will even be more efficient.
-gael
|
|
|
|
|
Community Member
|
|
Hi
The requirement for authorization is who (user name) doing what (action) on whom (the object). Let's say I have a routine in the Biz Logic Layer that fetches purchase orders for a. Then the who is the logged in user, the what is read, the whom is purchase order.
Question: how do I pass those parameters to the authorization routine using aspect oriented programming pattern using postsharp?
Thanks
BZ
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Hi Bz,
Who: I guess you get it from Thread.CurrentUser, HttpContext.User, or another thread-static field.
What: a property of your aspect.
Whom: AspectArgs.Instance.
See some sketch of this pattern on: <A href="http://www.sharpcrafters.com/solutions/security#secure-methods">http://www.sharpcrafters.com/solutions/security#secure-methods</A>
-gael
|
|
|
|
|
Community Member
|
|
Thanks for the prompt response.
I have a few more questions.
1. Our application is web based. Our BLL is a pure dll that can be used by asp.net or a windows app. I understand that a web based application should use HttpContext.CurrentUser and the non-webbased should use Thread.CurrentUser Our BLL does not reference to any http namespace. What should we use to pass the user principal information to the Authentication/Authorization module?
2. My second question is the concept of AOP-Security works nicely for class, method, properties. However our web application has the menus and buttons in the declarative aspx file (rather than create the control dynamically in the code behind). How do we assign authorization attribute to those web controls that are defined declaratively in the aspx file instead of in the code behind file?
Thanks a bunch.
BZ
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
|
1. Our application is web based. Our BLL is a pure dll that can be used by asp.net or a windows app. I understand that a web based application should use HttpContext.CurrentUser and the non-webbased should use Thread.CurrentUser Our BLL does not reference to any http namespace. What should we use to pass the user principal information to the Authentication/Authorization module?
You could check if Thread.Current
You could add a level of abstraction to get the current user:
public interface ISecurityContext
{
IPrincipal User { get; }
}
public static class SecurityContext
{
public static ISecurityContext Current { get; set; }
}
Then have every host (WinForms/DLL) of your DLL implement ISecurityContext and set the static property SecurityContext.Current upon initialization of the application.
2. My second question is the concept of AOP-Security works nicely for class, method, properties. However our web application has the menus and buttons in the declarative aspx file (rather than create the control dynamically in the code behind). How do we assign authorization attribute to those web controls that are defined declaratively in the aspx file instead of in the code behind file?
Here you're talking about [em]instances[/EM] of classes. You can't add aspects specifically to an instance of a class. But you can add aspects to event handlers that are clients of these instances, for instance.
|
|
|
|
|
Community Member
|
|
Hm, about question #2, I was thinking that a aspnet button such as "Search Product" is a member variable (or property) of a web user-control (such as HomePage.ascx) instance such as the homepage. Since the "Search Product" button is a property of a web user-control HomePage class, I can apply AOP to the button, right!?
Thanks
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
You can apply an aspect on the field or property, but I think it will not help; all you can do is to intercept get and set operations on this field.
If you need to disable/hide controls according to permissions of the current user, a more convential OO approach may be better, for instance iterating all fields of the type and looking for custom attributes.
-gael
|
|
|
|
Contacts
| Terms of Use |
Privacy Policy