I am trying to implment some business level user authorization in my current
..net 1.1 app. In C#, I would like to do something like:

[AuthorizationRule( "SomeRuleName" )]
public void MethodRequiringAuthorization()
{
... some code that requires authorization
}

But then have this code changed at compile time to something like:
public void MethodRequiringAuthorization()
{
if( Principal.Authorize( "SomeRuleName" ) )
{
... some code that requires authorization
}
}


Is there a way to do this? If not, is there some other way I can accomplish
the desired effect which is to decorate code with authorization rules
instead having to actually code it?

TIA//

Wouldn't it be more appropriate to throw a NotAuthorized Exception from
your AuthorizationRule class instead? - so that if the required
authorization rules are not met then the code that requires
authorization will not be executed (since the AuthorizationRule
Attribute class will be instantiated before the method is executed).

If you still need to continue further processing, then you should
probably catch the NotAuthorized Exception in the method calling
MethodRequiringAuthorization()

Regards,
Sarin.

Rather than a compile-time rewrite, have you considered using a custom
permission attribute? If that doesn't suit your requirements for some
reason, XC# (http://www.resolvecorp.com/) is capable of producing the sort
of compile-time code insertion that you've described.



"Chris Newby" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I am trying to implment some business level user authorization in my
>current
> .net 1.1 app. In C#, I would like to do something like:
>
> [AuthorizationRule( "SomeRuleName" )]
> public void MethodRequiringAuthorization()
> {
> ... some code that requires authorization
> }
>
> But then have this code changed at compile time to something like:
> public void MethodRequiringAuthorization()
> {
> if( Principal.Authorize( "SomeRuleName" ) )
> {
> ... some code that requires authorization
> }
> }
>
>
> Is there a way to do this? If not, is there some other way I can
> accomplish
> the desired effect which is to decorate code with authorization rules
> instead having to actually code it?
>
> TIA//
>
>
>
>

In fact, my plan is to throw an exception from the call to Authorize(). In
the code outline of my original post, I was just trying to make it clear
that the "inner" code of the method would not be run if the Authorize() call
failed (or literally in that case returned false).

My primary concern was not so much the logic of my authorization rules, but
instead how I declare the authorization rules in my code. Given the
following method:

public Customer GetCustomer( String Id )
{
... logic that gets an instance of Customer
}

To me, authorization rules don't necessarily have anything to do with the
logic of getting an instance of Customer, and therefore a method that looks
like:

public Customer GetCustomer( String Id )
{
if( Principal.Authorize( "GetCustomerAuthorizationRule" ) )
{
... logic that gets an instance of Customer
}
}

Now has two purposes instead of just one ... authorization and Customer
object logic. In short, it's a bit less elegant than:

[AuthorizationRule( "GetCustomerAuthorizationRule" )]
public Customer GetCustomer( String Id )
{
... logic that gets an instance of Customer
}


<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Wouldn't it be more appropriate to throw a NotAuthorized Exception from
> your AuthorizationRule class instead? - so that if the required
> authorization rules are not met then the code that requires
> authorization will not be executed (since the AuthorizationRule
> Attribute class will be instantiated before the method is executed).
>
> If you still need to continue further processing, then you should
> probably catch the NotAuthorized Exception in the method calling
> MethodRequiringAuthorization()
>
> Regards,
> Sarin.
>

Nicole, I just looked this up on MSDN ... are you talking about creating an
attribute that derives from SecurityAttribute? If so, do you have a short
example perhaps? If not ... ... what do you mean by "custom permission
attribute"?

Thanks,
Chris

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:%(E-Mail Removed)...
> Rather than a compile-time rewrite, have you considered using a custom
> permission attribute? If that doesn't suit your requirements for some
> reason, XC# (http://www.resolvecorp.com/) is capable of producing the sort
> of compile-time code insertion that you've described.
>
>
>
> "Chris Newby" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>I am trying to implment some business level user authorization in my
>>current
>> .net 1.1 app. In C#, I would like to do something like:
>>
>> [AuthorizationRule( "SomeRuleName" )]
>> public void MethodRequiringAuthorization()
>> {
>> ... some code that requires authorization
>> }
>>
>> But then have this code changed at compile time to something like:
>> public void MethodRequiringAuthorization()
>> {
>> if( Principal.Authorize( "SomeRuleName" ) )
>> {
>> ... some code that requires authorization
>> }
>> }
>>
>>
>> Is there a way to do this? If not, is there some other way I can
>> accomplish
>> the desired effect which is to decorate code with authorization rules
>> instead having to actually code it?
>>
>> TIA//
>>
>>
>>
>>
>
>

Yes, I was referring to an attribute that derives from SecurityAttribute.
However, you actually need to derive from its CodeAccessSecurityAttribute
subclass in order for the CAS plumbing to recognize your attribute
correctly. AFAIK, the most complete sample of a non-stack walking
permission with attribute is at
http://blogs.msdn.com/eugene_bobukh/.../10/87645.aspx. You
might also want to take a look at the PrincipalPermission and
PrincipalPermissionAttribute implementations with Reflector or another
decompiler since your permission would presumably be rather similar in quite
a few ways.

Also, there are a few things to watch out for:

1. In order to be recognized by the CLR in v. 1.1, your permission
attribute's assembly must be registered as a policy assembly, which means it
must also be in the GAC, which means it must also be strongly named. The
details of how to work with these requirements during development are
covered in Eugene Bobukh's sample.

2. Many folks run into trouble because they fail to implement the ToXml and
FromXml methods correctly on the permission class. These are absolutely
necessary for the attribute to work correctly, so don't even bother trying
to use the attribute until you've tested them.

On a bit of a side note, you may want to consider the implications of #1 wrt
your production environment. A permission attribute that isn't in a policy
assembly just gets ignored, so it's possible to bypass the protection that
your attribute instances will be meant to provide simply by removing your
permission attribute assembly from the policy assemblies list. This means
that the attributes can't be trusted to be active on machines that are
outside your control. This is generally a bigger problem on client machines
than on servers, and even the client machine problem would usually be
mitigated by permission re-verification on target servers, but it's
something that you should probably consider before committing to this
approach.




"Chris Newby" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Nicole, I just looked this up on MSDN ... are you talking about creating
> an attribute that derives from SecurityAttribute? If so, do you have a
> short example perhaps? If not ... ... what do you mean by "custom
> permission attribute"?
>
> Thanks,
> Chris
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:%(E-Mail Removed)...
>> Rather than a compile-time rewrite, have you considered using a custom
>> permission attribute? If that doesn't suit your requirements for some
>> reason, XC# (http://www.resolvecorp.com/) is capable of producing the
>> sort of compile-time code insertion that you've described.
>>
>>
>>
>> "Chris Newby" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>I am trying to implment some business level user authorization in my
>>>current
>>> .net 1.1 app. In C#, I would like to do something like:
>>>
>>> [AuthorizationRule( "SomeRuleName" )]
>>> public void MethodRequiringAuthorization()
>>> {
>>> ... some code that requires authorization
>>> }
>>>
>>> But then have this code changed at compile time to something like:
>>> public void MethodRequiringAuthorization()
>>> {
>>> if( Principal.Authorize( "SomeRuleName" ) )
>>> {
>>> ... some code that requires authorization
>>> }
>>> }
>>>
>>>
>>> Is there a way to do this? If not, is there some other way I can
>>> accomplish
>>> the desired effect which is to decorate code with authorization rules
>>> instead having to actually code it?
>>>
>>> TIA//
>>>
>>>
>>>
>>>
>>
>>
>
>

Wow Nicole ... awesome ... thanks for all the feedback. I haven't had a
chance to check out AFAIK as of yet, but will soon.

Just wanted to premptively say thanks a bunch in case I forget later.


"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:(E-Mail Removed)...
> Yes, I was referring to an attribute that derives from SecurityAttribute.
> However, you actually need to derive from its CodeAccessSecurityAttribute
> subclass in order for the CAS plumbing to recognize your attribute
> correctly. AFAIK, the most complete sample of a non-stack walking
> permission with attribute is at
> http://blogs.msdn.com/eugene_bobukh/.../10/87645.aspx. You
> might also want to take a look at the PrincipalPermission and
> PrincipalPermissionAttribute implementations with Reflector or another
> decompiler since your permission would presumably be rather similar in
> quite a few ways.
>
> Also, there are a few things to watch out for:
>
> 1. In order to be recognized by the CLR in v. 1.1, your permission
> attribute's assembly must be registered as a policy assembly, which means
> it must also be in the GAC, which means it must also be strongly named.
> The details of how to work with these requirements during development are
> covered in Eugene Bobukh's sample.
>
> 2. Many folks run into trouble because they fail to implement the ToXml
> and FromXml methods correctly on the permission class. These are
> absolutely necessary for the attribute to work correctly, so don't even
> bother trying to use the attribute until you've tested them.
>
> On a bit of a side note, you may want to consider the implications of #1
> wrt your production environment. A permission attribute that isn't in a
> policy assembly just gets ignored, so it's possible to bypass the
> protection that your attribute instances will be meant to provide simply
> by removing your permission attribute assembly from the policy assemblies
> list. This means that the attributes can't be trusted to be active on
> machines that are outside your control. This is generally a bigger
> problem on client machines than on servers, and even the client machine
> problem would usually be mitigated by permission re-verification on target
> servers, but it's something that you should probably consider before
> committing to this approach.
>
>
>
>
> "Chris Newby" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Nicole, I just looked this up on MSDN ... are you talking about creating
>> an attribute that derives from SecurityAttribute? If so, do you have a
>> short example perhaps? If not ... ... what do you mean by "custom
>> permission attribute"?
>>
>> Thanks,
>> Chris
>>
>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
>> news:%(E-Mail Removed)...
>>> Rather than a compile-time rewrite, have you considered using a custom
>>> permission attribute? If that doesn't suit your requirements for some
>>> reason, XC# (http://www.resolvecorp.com/) is capable of producing the
>>> sort of compile-time code insertion that you've described.
>>>
>>>
>>>
>>> "Chris Newby" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>>I am trying to implment some business level user authorization in my
>>>>current
>>>> .net 1.1 app. In C#, I would like to do something like:
>>>>
>>>> [AuthorizationRule( "SomeRuleName" )]
>>>> public void MethodRequiringAuthorization()
>>>> {
>>>> ... some code that requires authorization
>>>> }
>>>>
>>>> But then have this code changed at compile time to something like:
>>>> public void MethodRequiringAuthorization()
>>>> {
>>>> if( Principal.Authorize( "SomeRuleName" ) )
>>>> {
>>>> ... some code that requires authorization
>>>> }
>>>> }
>>>>
>>>>
>>>> Is there a way to do this? If not, is there some other way I can
>>>> accomplish
>>>> the desired effect which is to decorate code with authorization rules
>>>> instead having to actually code it?
>>>>
>>>> TIA//
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

Nicole ... this worked brilliantly ... just wanted to thank you again.

Chris


"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:(E-Mail Removed)...
> Yes, I was referring to an attribute that derives from SecurityAttribute.
> However, you actually need to derive from its CodeAccessSecurityAttribute
> subclass in order for the CAS plumbing to recognize your attribute
> correctly. AFAIK, the most complete sample of a non-stack walking
> permission with attribute is at
> http://blogs.msdn.com/eugene_bobukh/.../10/87645.aspx. You
> might also want to take a look at the PrincipalPermission and
> PrincipalPermissionAttribute implementations with Reflector or another
> decompiler since your permission would presumably be rather similar in
> quite a few ways.
>
> Also, there are a few things to watch out for:
>
> 1. In order to be recognized by the CLR in v. 1.1, your permission
> attribute's assembly must be registered as a policy assembly, which means
> it must also be in the GAC, which means it must also be strongly named.
> The details of how to work with these requirements during development are
> covered in Eugene Bobukh's sample.
>
> 2. Many folks run into trouble because they fail to implement the ToXml
> and FromXml methods correctly on the permission class. These are
> absolutely necessary for the attribute to work correctly, so don't even
> bother trying to use the attribute until you've tested them.
>
> On a bit of a side note, you may want to consider the implications of #1
> wrt your production environment. A permission attribute that isn't in a
> policy assembly just gets ignored, so it's possible to bypass the
> protection that your attribute instances will be meant to provide simply
> by removing your permission attribute assembly from the policy assemblies
> list. This means that the attributes can't be trusted to be active on
> machines that are outside your control. This is generally a bigger
> problem on client machines than on servers, and even the client machine
> problem would usually be mitigated by permission re-verification on target
> servers, but it's something that you should probably consider before
> committing to this approach.
>
>
>
>
> "Chris Newby" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Nicole, I just looked this up on MSDN ... are you talking about creating
>> an attribute that derives from SecurityAttribute? If so, do you have a
>> short example perhaps? If not ... ... what do you mean by "custom
>> permission attribute"?
>>
>> Thanks,
>> Chris
>>
>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
>> news:%(E-Mail Removed)...
>>> Rather than a compile-time rewrite, have you considered using a custom
>>> permission attribute? If that doesn't suit your requirements for some
>>> reason, XC# (http://www.resolvecorp.com/) is capable of producing the
>>> sort of compile-time code insertion that you've described.
>>>
>>>
>>>
>>> "Chris Newby" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>>I am trying to implment some business level user authorization in my
>>>>current
>>>> .net 1.1 app. In C#, I would like to do something like:
>>>>
>>>> [AuthorizationRule( "SomeRuleName" )]
>>>> public void MethodRequiringAuthorization()
>>>> {
>>>> ... some code that requires authorization
>>>> }
>>>>
>>>> But then have this code changed at compile time to something like:
>>>> public void MethodRequiringAuthorization()
>>>> {
>>>> if( Principal.Authorize( "SomeRuleName" ) )
>>>> {
>>>> ... some code that requires authorization
>>>> }
>>>> }
>>>>
>>>>
>>>> Is there a way to do this? If not, is there some other way I can
>>>> accomplish
>>>> the desired effect which is to decorate code with authorization rules
>>>> instead having to actually code it?
>>>>
>>>> TIA//
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>