Design Question

[John Lee]

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

 

[Nicole Calinoiu]

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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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

 

[Anders Borum [.NET/C# MCP]]

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.

 

[John Lee]

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

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]
- (e-mail address removed)

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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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

 

[Nicole Calinoiu]

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

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

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]
- (e-mail address removed)

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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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



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

 

[Nicole Calinoiu]

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

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]
- (e-mail address removed)

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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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

 

[Nicholas Paldino [.NET/C# MVP]]

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]
- (e-mail address removed)

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

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]
- (e-mail address removed)

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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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



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

 

[John Lee]

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

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]
- (e-mail address removed)

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

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]
- (e-mail address removed)


"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in
message 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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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



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

 

[Nicholas Paldino [.NET/C# MVP]]

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]
- (e-mail address removed)

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

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]
- (e-mail address removed)

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



in message 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]
- (e-mail address removed)


"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in
message 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-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.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



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