By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,179 Members | 1,144 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,179 IT Pros & Developers. It's quick & easy.

Design Question

P: n/a
Hi,

If I want to check permission on each public method of a web service,
(assume the checking routine is ready to use and called AccessCheck) , one
way of doing it is to call this AccessCheck on top of each public method, I
want to implement it in different way but seems missing something -

I want to develop a custom attribute, let's say
SecurityCheckEnabledAttribute with only Yes/No parameter, then create a base
class for all web service classes, Is there any way to capture the public
method call from base class at runtime and then check if the attribute is
being applied and then check the permission?

Thanks a lot!

Regards,
John
Nov 16 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Yes, but it's probably not as simple as you might have hoped. Here are the
three main approaches:

1. Implement the check as a custom permission with a corresponding
attribute
(http://msdn.microsoft.com/library/en...rmissions.asp).
This may be your best bet since you can presumably control whether the
attribute assembly is registered as a trusted assembly.

2. Place the actual method work in objects that inherit from
System.ContextBoundObject. This might interfere with your planned object
hierarchy, as well as introducing an otherwise unnecessary performance hit.

3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
generate inline code that corresponds to your custom attribute.

If this truly is a security permission, #1 is probably the "cleanest"
approach. Otherwise, #3 would probably offer the best compromise between
design-time convenience and runtime performance.

HTH,
Nicole

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:ej****************@TK2MSFTNGP10.phx.gbl...
Hi,

If I want to check permission on each public method of a web service,
(assume the checking routine is ready to use and called AccessCheck) , one
way of doing it is to call this AccessCheck on top of each public method,
I want to implement it in different way but seems missing something -

I want to develop a custom attribute, let's say
SecurityCheckEnabledAttribute with only Yes/No parameter, then create a
base class for all web service classes, Is there any way to capture the
public method call from base class at runtime and then check if the
attribute is being applied and then check the permission?

Thanks a lot!

Regards,
John

Nov 16 '05 #2

P: n/a
Hello!

Don't forget that if the Principal and/or Identity instances are expensive
to create, you might want to implement a caching schema to save resources.

--
venlig hilsen / with regards
anders borum (mcp)
--
Nov 16 '05 #3

P: n/a
Thanks very much for the reply.

But all role-based security information resides in AzMan store. All web
services are configured as Windows authentication in IIS. So I will have to
first get the Windows principal and then call AzRoles.dll's
AccessCheck("method name") - each method name will be defined as an
"operation" in AzMan store.

Regards,
John

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Or****************@tk2msftngp13.phx.gbl...
Or (and I think this is the easiest one of all), just use a custom
principal, and let Code Access Security take care of the rest. Basically,
you implement IPrincipal, and set it as the principal for the thread that
is doing the processing.

Attached is a console application which demonstrates how to use the
PrincipalPermission attribute. Basically, there is an implementation of
IPrincipal and the current thread is set to use that principal (you will
have to do something different to have web requests use a certain
principal, but Im sure you can do it). Then, you just apply the right
attribute to your method, and the runtime will take care of the rest.

Try changing the IsInRole implementation to return something else, or
the declaration of the PrincipalPermission attribute and the call to
DoSomething will fail.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...
Yes, but it's probably not as simple as you might have hoped. Here are
the
three main approaches:

1. Implement the check as a custom permission with a corresponding
attribute
(http://msdn.microsoft.com/library/en...rmissions.asp).
This may be your best bet since you can presumably control whether the
attribute assembly is registered as a trusted assembly.

2. Place the actual method work in objects that inherit from
System.ContextBoundObject. This might interfere with your planned object
hierarchy, as well as introducing an otherwise unnecessary performance
hit.

3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
generate inline code that corresponds to your custom attribute.

If this truly is a security permission, #1 is probably the "cleanest"
approach. Otherwise, #3 would probably offer the best compromise between
design-time convenience and runtime performance.

HTH,
Nicole

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:ej****************@TK2MSFTNGP10.phx.gbl...
Hi,

If I want to check permission on each public method of a web service,
(assume the checking routine is ready to use and called AccessCheck) ,
one
way of doing it is to call this AccessCheck on top of each public
method,
I want to implement it in different way but seems missing something -

I want to develop a custom attribute, let's say
SecurityCheckEnabledAttribute with only Yes/No parameter, then create a
base class for all web service classes, Is there any way to capture the
public method call from base class at runtime and then check if the
attribute is being applied and then check the permission?

Thanks a lot!

Regards,
John



Nov 16 '05 #4

P: n/a
Not sure why, but I didn't even consider that this might have anything to do
with the principal when I answered yesterday. That said, even if it is
reasonably simple to swap out the principal for a web service, it's still
not necessarily a great idea to do so. While using Windows-integrated
authentication for web services is certainly simple, investing additional
effort into tweaking the behaviour of a non-standard authentication
mechanism probably isn't the best use of most folks' time...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Or****************@tk2msftngp13.phx.gbl...
Or (and I think this is the easiest one of all), just use a custom
principal, and let Code Access Security take care of the rest. Basically,
you implement IPrincipal, and set it as the principal for the thread that
is doing the processing.

Attached is a console application which demonstrates how to use the
PrincipalPermission attribute. Basically, there is an implementation of
IPrincipal and the current thread is set to use that principal (you will
have to do something different to have web requests use a certain
principal, but Im sure you can do it). Then, you just apply the right
attribute to your method, and the runtime will take care of the rest.

Try changing the IsInRole implementation to return something else, or
the declaration of the PrincipalPermission attribute and the call to
DoSomething will fail.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...
Yes, but it's probably not as simple as you might have hoped. Here are
the
three main approaches:

1. Implement the check as a custom permission with a corresponding
attribute
(http://msdn.microsoft.com/library/en...rmissions.asp).
This may be your best bet since you can presumably control whether the
attribute assembly is registered as a trusted assembly.

2. Place the actual method work in objects that inherit from
System.ContextBoundObject. This might interfere with your planned object
hierarchy, as well as introducing an otherwise unnecessary performance
hit.

3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
generate inline code that corresponds to your custom attribute.

If this truly is a security permission, #1 is probably the "cleanest"
approach. Otherwise, #3 would probably offer the best compromise between
design-time convenience and runtime performance.

HTH,
Nicole

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:ej****************@TK2MSFTNGP10.phx.gbl...
Hi,

If I want to check permission on each public method of a web service,
(assume the checking routine is ready to use and called AccessCheck) ,
one
way of doing it is to call this AccessCheck on top of each public
method,
I want to implement it in different way but seems missing something -

I want to develop a custom attribute, let's say
SecurityCheckEnabledAttribute with only Yes/No parameter, then create a
base class for all web service classes, Is there any way to capture the
public method call from base class at runtime and then check if the
attribute is being applied and then check the permission?

Thanks a lot!

Regards,
John



Nov 16 '05 #5

P: n/a
John,

Your biggest problem with this is likely to be determining the name of the
method. Unfortunately, the permissions attributes have no built-in
mechanism for directly retrieving a reference to the attribute target.
While it might be possible to retrieve such a reference using a combination
of stack walking and reflection at runtime, this would have potentially
undesirable performance consequences. To avoid these, you would need to
either hard-code the operation name (or some mapping value) into the
attribute definition (regardless of you're implementing with a custom
permission or a principal permission with custom principal) or use a tool
like XC# that will do the heavy lifting at compile time rather than at
runtime. Personally, I wouldn't opt for the hard-coding approach since
security holes could be opened by simply missing an edit during code
maintenance, but YMMV...

HTH,
Nicole


"John Lee" <jo***@newsgroup.nospam> wrote in message
news:uc*************@TK2MSFTNGP10.phx.gbl...
Thanks very much for the reply.

But all role-based security information resides in AzMan store. All web
services are configured as Windows authentication in IIS. So I will have
to first get the Windows principal and then call AzRoles.dll's
AccessCheck("method name") - each method name will be defined as an
"operation" in AzMan store.

Regards,
John

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:Or****************@tk2msftngp13.phx.gbl...
Or (and I think this is the easiest one of all), just use a custom
principal, and let Code Access Security take care of the rest.
Basically, you implement IPrincipal, and set it as the principal for the
thread that is doing the processing.

Attached is a console application which demonstrates how to use the
PrincipalPermission attribute. Basically, there is an implementation of
IPrincipal and the current thread is set to use that principal (you will
have to do something different to have web requests use a certain
principal, but Im sure you can do it). Then, you just apply the right
attribute to your method, and the runtime will take care of the rest.

Try changing the IsInRole implementation to return something else, or
the declaration of the PrincipalPermission attribute and the call to
DoSomething will fail.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...
Yes, but it's probably not as simple as you might have hoped. Here are
the
three main approaches:

1. Implement the check as a custom permission with a corresponding
attribute
(http://msdn.microsoft.com/library/en...rmissions.asp).
This may be your best bet since you can presumably control whether the
attribute assembly is registered as a trusted assembly.

2. Place the actual method work in objects that inherit from
System.ContextBoundObject. This might interfere with your planned
object
hierarchy, as well as introducing an otherwise unnecessary performance
hit.

3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
generate inline code that corresponds to your custom attribute.

If this truly is a security permission, #1 is probably the "cleanest"
approach. Otherwise, #3 would probably offer the best compromise
between
design-time convenience and runtime performance.

HTH,
Nicole

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:ej****************@TK2MSFTNGP10.phx.gbl...
Hi,

If I want to check permission on each public method of a web service,
(assume the checking routine is ready to use and called AccessCheck) ,
one
way of doing it is to call this AccessCheck on top of each public
method,
I want to implement it in different way but seems missing something -

I want to develop a custom attribute, let's say
SecurityCheckEnabledAttribute with only Yes/No parameter, then create a
base class for all web service classes, Is there any way to capture the
public method call from base class at runtime and then check if the
attribute is being applied and then check the permission?

Thanks a lot!

Regards,
John



Nov 16 '05 #6

P: n/a
Nicole,

It doesn't have to a Windows-integrated authentication scheme. That's
the beauty of the design, it allows for any implementation. One just has to
define the roles.

Because Windows authentication is being used, the easiest thing to do
would be to create windows groups based on the names of the web methods that
you want to call. Then, assign users to the groups that you want to have
access (if you can do this through AD, great, however, maintaining this
compared to setting an AccessCheck table on AD is going to be the same in
terms of overhead).

ASP.NET should be able to impersonate the user (set the impersonate flag
to true in web.config), and then you don't have to do anything regarding the
principal, it will just work.

Also, it will be easier to maintain the code, since you won't have to
code the call to check security every time your method is called (or every
time you create a new method), you just have to attribute the method and it
works.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:el*************@TK2MSFTNGP14.phx.gbl...
Not sure why, but I didn't even consider that this might have anything to
do with the principal when I answered yesterday. That said, even if it is
reasonably simple to swap out the principal for a web service, it's still
not necessarily a great idea to do so. While using Windows-integrated
authentication for web services is certainly simple, investing additional
effort into tweaking the behaviour of a non-standard authentication
mechanism probably isn't the best use of most folks' time...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:Or****************@tk2msftngp13.phx.gbl...
Or (and I think this is the easiest one of all), just use a custom
principal, and let Code Access Security take care of the rest.
Basically, you implement IPrincipal, and set it as the principal for the
thread that is doing the processing.

Attached is a console application which demonstrates how to use the
PrincipalPermission attribute. Basically, there is an implementation of
IPrincipal and the current thread is set to use that principal (you will
have to do something different to have web requests use a certain
principal, but Im sure you can do it). Then, you just apply the right
attribute to your method, and the runtime will take care of the rest.

Try changing the IsInRole implementation to return something else, or
the declaration of the PrincipalPermission attribute and the call to
DoSomething will fail.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...
Yes, but it's probably not as simple as you might have hoped. Here are
the
three main approaches:

1. Implement the check as a custom permission with a corresponding
attribute
(http://msdn.microsoft.com/library/en...rmissions.asp).
This may be your best bet since you can presumably control whether the
attribute assembly is registered as a trusted assembly.

2. Place the actual method work in objects that inherit from
System.ContextBoundObject. This might interfere with your planned
object
hierarchy, as well as introducing an otherwise unnecessary performance
hit.

3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
generate inline code that corresponds to your custom attribute.

If this truly is a security permission, #1 is probably the "cleanest"
approach. Otherwise, #3 would probably offer the best compromise
between
design-time convenience and runtime performance.

HTH,
Nicole

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:ej****************@TK2MSFTNGP10.phx.gbl...
Hi,

If I want to check permission on each public method of a web service,
(assume the checking routine is ready to use and called AccessCheck) ,
one
way of doing it is to call this AccessCheck on top of each public
method,
I want to implement it in different way but seems missing something -

I want to develop a custom attribute, let's say
SecurityCheckEnabledAttribute with only Yes/No parameter, then create a
base class for all web service classes, Is there any way to capture the
public method call from base class at runtime and then check if the
attribute is being applied and then check the permission?

Thanks a lot!

Regards,
John



Nov 16 '05 #7

P: n/a
Thanks for your suggestion.

So you are saying DO NOT use Authorization Manager (AzMan) for role-based
security? Mapping User or Group directly to method call (creating security
group in AD) is the best way to go?

Thanks!
John

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uh*************@TK2MSFTNGP09.phx.gbl...
Nicole,

It doesn't have to a Windows-integrated authentication scheme. That's
the beauty of the design, it allows for any implementation. One just has
to define the roles.

Because Windows authentication is being used, the easiest thing to do
would be to create windows groups based on the names of the web methods
that you want to call. Then, assign users to the groups that you want to
have access (if you can do this through AD, great, however, maintaining
this compared to setting an AccessCheck table on AD is going to be the
same in terms of overhead).

ASP.NET should be able to impersonate the user (set the impersonate
flag to true in web.config), and then you don't have to do anything
regarding the principal, it will just work.

Also, it will be easier to maintain the code, since you won't have to
code the call to check security every time your method is called (or every
time you create a new method), you just have to attribute the method and
it works.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:el*************@TK2MSFTNGP14.phx.gbl...
Not sure why, but I didn't even consider that this might have anything to
do with the principal when I answered yesterday. That said, even if it
is reasonably simple to swap out the principal for a web service, it's
still not necessarily a great idea to do so. While using
Windows-integrated authentication for web services is certainly simple,
investing additional effort into tweaking the behaviour of a non-standard
authentication mechanism probably isn't the best use of most folks'
time...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:Or****************@tk2msftngp13.phx.gbl...
Or (and I think this is the easiest one of all), just use a custom
principal, and let Code Access Security take care of the rest.
Basically, you implement IPrincipal, and set it as the principal for the
thread that is doing the processing.

Attached is a console application which demonstrates how to use the
PrincipalPermission attribute. Basically, there is an implementation of
IPrincipal and the current thread is set to use that principal (you will
have to do something different to have web requests use a certain
principal, but Im sure you can do it). Then, you just apply the right
attribute to your method, and the runtime will take care of the rest.

Try changing the IsInRole implementation to return something else, or
the declaration of the PrincipalPermission attribute and the call to
DoSomething will fail.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in
message news:O5**************@TK2MSFTNGP12.phx.gbl...
Yes, but it's probably not as simple as you might have hoped. Here are
the
three main approaches:

1. Implement the check as a custom permission with a corresponding
attribute
(http://msdn.microsoft.com/library/en...rmissions.asp).
This may be your best bet since you can presumably control whether the
attribute assembly is registered as a trusted assembly.

2. Place the actual method work in objects that inherit from
System.ContextBoundObject. This might interfere with your planned
object
hierarchy, as well as introducing an otherwise unnecessary performance
hit.

3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
generate inline code that corresponds to your custom attribute.

If this truly is a security permission, #1 is probably the "cleanest"
approach. Otherwise, #3 would probably offer the best compromise
between
design-time convenience and runtime performance.

HTH,
Nicole

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:ej****************@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> If I want to check permission on each public method of a web service,
> (assume the checking routine is ready to use and called AccessCheck) ,
> one
> way of doing it is to call this AccessCheck on top of each public
> method,
> I want to implement it in different way but seems missing something -
>
> I want to develop a custom attribute, let's say
> SecurityCheckEnabledAttribute with only Yes/No parameter, then create
> a
> base class for all web service classes, Is there any way to capture
> the
> public method call from base class at runtime and then check if the
> attribute is being applied and then check the permission?
>
> Thanks a lot!
>
> Regards,
> John
>




Nov 16 '05 #8

P: n/a
John,

I'm not exactly sure how the interaction between the WindowsPrincipal
and AD works. I believe there are some ties, but I am not positive. Since
you have IIS set up to impersonate the caller (and you will set up ASP.NET
as well), you will want the value of IsInRole to return true if they are in
a group that has the name of the web method.

The key is to assign the users in AD to a group that is recognized by
the windows principal. I believe this can be done (instead of using
AccessChecks).

CAS uses a role based scheme for providing security based on a
principal, assuming that if a user is in a group/role, then they have
permission to do something. You just have to change the information you
have about principals to reflect that.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Lee" <jo***@newsgroup.nospam> wrote in message
news:e3****************@TK2MSFTNGP09.phx.gbl...
Thanks for your suggestion.

So you are saying DO NOT use Authorization Manager (AzMan) for role-based
security? Mapping User or Group directly to method call (creating security
group in AD) is the best way to go?

Thanks!
John

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:uh*************@TK2MSFTNGP09.phx.gbl...
Nicole,

It doesn't have to a Windows-integrated authentication scheme. That's
the beauty of the design, it allows for any implementation. One just has
to define the roles.

Because Windows authentication is being used, the easiest thing to do
would be to create windows groups based on the names of the web methods
that you want to call. Then, assign users to the groups that you want to
have access (if you can do this through AD, great, however, maintaining
this compared to setting an AccessCheck table on AD is going to be the
same in terms of overhead).

ASP.NET should be able to impersonate the user (set the impersonate
flag to true in web.config), and then you don't have to do anything
regarding the principal, it will just work.

Also, it will be easier to maintain the code, since you won't have to
code the call to check security every time your method is called (or
every time you create a new method), you just have to attribute the
method and it works.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:el*************@TK2MSFTNGP14.phx.gbl...
Not sure why, but I didn't even consider that this might have anything
to do with the principal when I answered yesterday. That said, even if
it is reasonably simple to swap out the principal for a web service,
it's still not necessarily a great idea to do so. While using
Windows-integrated authentication for web services is certainly simple,
investing additional effort into tweaking the behaviour of a
non-standard authentication mechanism probably isn't the best use of
most folks' time...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:Or****************@tk2msftngp13.phx.gbl...
Or (and I think this is the easiest one of all), just use a custom
principal, and let Code Access Security take care of the rest.
Basically, you implement IPrincipal, and set it as the principal for
the thread that is doing the processing.

Attached is a console application which demonstrates how to use the
PrincipalPermission attribute. Basically, there is an implementation
of IPrincipal and the current thread is set to use that principal (you
will have to do something different to have web requests use a certain
principal, but Im sure you can do it). Then, you just apply the right
attribute to your method, and the runtime will take care of the rest.

Try changing the IsInRole implementation to return something else,
or the declaration of the PrincipalPermission attribute and the call to
DoSomething will fail.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in
message news:O5**************@TK2MSFTNGP12.phx.gbl...
> Yes, but it's probably not as simple as you might have hoped. Here
> are the
> three main approaches:
>
> 1. Implement the check as a custom permission with a corresponding
> attribute
> (http://msdn.microsoft.com/library/en...rmissions.asp).
> This may be your best bet since you can presumably control whether
> the
> attribute assembly is registered as a trusted assembly.
>
> 2. Place the actual method work in objects that inherit from
> System.ContextBoundObject. This might interfere with your planned
> object
> hierarchy, as well as introducing an otherwise unnecessary performance
> hit.
>
> 3. Use a tool like XC# (http://www.resolvecorp.com/Products.aspx) to
> generate inline code that corresponds to your custom attribute.
>
> If this truly is a security permission, #1 is probably the "cleanest"
> approach. Otherwise, #3 would probably offer the best compromise
> between
> design-time convenience and runtime performance.
>
> HTH,
> Nicole
>
>
>
> "John Lee" <jo***@newsgroup.nospam> wrote in message
> news:ej****************@TK2MSFTNGP10.phx.gbl...
>> Hi,
>>
>> If I want to check permission on each public method of a web service,
>> (assume the checking routine is ready to use and called AccessCheck)
>> , one
>> way of doing it is to call this AccessCheck on top of each public
>> method,
>> I want to implement it in different way but seems missing something -
>>
>> I want to develop a custom attribute, let's say
>> SecurityCheckEnabledAttribute with only Yes/No parameter, then create
>> a
>> base class for all web service classes, Is there any way to capture
>> the
>> public method call from base class at runtime and then check if the
>> attribute is being applied and then check the permission?
>>
>> Thanks a lot!
>>
>> Regards,
>> John
>>
>
>




Nov 16 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.