Per-method role management

[Jon Skeet [C# MVP]]

I've got a web service where different methods require different roles,
and I'm trying to enforce that now.

I've worked out *one* way of doing things, using
PrincipalPermissionAttribute - but that ends up with a response of 500
rather than a 403.

What's the best way of demanding roles for execution of individual web
methods? Obviously I can write a CheckRole method which sets the
response code appropriately, but then if I'm executing a method which
takes parameters, how do I tell the web method not to write all the
rest of the normal response out? Response.End()?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Drew Robbins]

When making a web request over http, the status code 500 is the response
for most exceptions.

You may want to look at the Policy mechanism in WSE 2.0 to enforce
role-based authorization.

http://msdn.microsoft.com/library/de...e2wspolicy.asp

Jon Skeet [C# MVP] wrote:

I've got a web service where different methods require different roles,
and I'm trying to enforce that now.

I've worked out *one* way of doing things, using
PrincipalPermissionAttribute - but that ends up with a response of 500
rather than a 403.

What's the best way of demanding roles for execution of individual web
methods? Obviously I can write a CheckRole method which sets the
response code appropriately, but then if I'm executing a method which
takes parameters, how do I tell the web method not to write all the
rest of the normal response out? Response.End()?

[Jon Skeet [C# MVP]]

<Drew Robbins <"drew at drewby.com">> wrote:

When making a web request over http, the status code 500 is the response
for most exceptions.
Yes - it shouldn't be for this condition though :(
You may want to look at the Policy mechanism in WSE 2.0 to enforce
role-based authorization.

http://msdn.microsoft.com/library/de...ary/en-us/dnws
e/html/wse2wspolicy.asp

Right. I've been trying to avoid all of that stuff for the moment
(partly because I'm using the Compact Framework to talk to the
webservice, so I want to keep things simple).

I think I'll just work out some way of returning normally from the
method having set the response code, and suppress the content of the
response.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sami Vaaraniemi]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

<Drew Robbins <"drew at drewby.com">> wrote:

When making a web request over http, the status code 500 is the response
for most exceptions.
Yes - it shouldn't be for this condition though :(

To return HTTP code 403 you might have to fail it already in the HttpModule
where you do the digest authentication (I'm not sure if you can hack the web
method somehow to get it to return HTTP 403 (see (*)). Handling it in the
HttpModule *and* also allow declarative permissions in the web methods, you
would have to reflect the web method, see if it has the PrincipalPermission
attribute, then check if the user belongs to the role and then possibly
fail. This is a fair amount of work and you'd be writing similar plumbing
that WSE gives you pretty much out of the box...

A bigger question is is it ok to couple the authentication logic with
transport? This depends largely on your requirements, but in general, HTTP
digest authentication for web services is a dead-end as are all
transport-based authentication schemes. They won't do if you want to
authenticate over other transports, over multiple hops, or have support for
WS-Security. Again, WSE would be the real answer here.

(*) I made a quick experiment with the following code in the web method:

Context.Response.Clear();
Context.Response.StatusCode = 403;
Context.Response.StatusDescription = "Access Denied";
Context.Response.Write("<h2>Access Denied</h2>");
Context.Response.End();

but it just ends up returning error code 500 anyway with a
ThreadAbortException. Most likely the Web Service infrastructure in ASP.NET
does not like you trying to change the HTTP response from within the web
method.

You may want to look at the Policy mechanism in WSE 2.0 to enforce
role-based authorization.

http://msdn.microsoft.com/library/de...ary/en-us/dnws
e/html/wse2wspolicy.asp

Right. I've been trying to avoid all of that stuff for the moment
(partly because I'm using the Compact Framework to talk to the
webservice, so I want to keep things simple).

I think I'll just work out some way of returning normally from the
method having set the response code, and suppress the content of the
response.

As it sometimes happens, trying to keep it simple may end up making things
unnecessarily complicated :)

Regards and YMMV,
Sami

[Jon Skeet [C# MVP]]

Sami Vaaraniemi <sa**********@pleasejippii.fi> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

<Drew Robbins <"drew at drewby.com">> wrote:

When making a web request over http, the status code 500 is the response
for most exceptions.
Yes - it shouldn't be for this condition though :(

To return HTTP code 403 you might have to fail it already in the HttpModule
where you do the digest authentication (I'm not sure if you can hack the web
method somehow to get it to return HTTP 403 (see (*)). Handling it in the
HttpModule *and* also allow declarative permissions in the web methods, you
would have to reflect the web method, see if it has the PrincipalPermission
attribute, then check if the user belongs to the role and then possibly
fail. This is a fair amount of work and you'd be writing similar plumbing
that WSE gives you pretty much out of the box...

Yes - unfortunately WSE isn't in the picture at the moment.

I'm getting somewhere setting the HTTP code in the web service, but
still investigating at the moment. Unfortunately, it's fairly hard to
look at what's coming down the wire when I'm testing with a Pocket PC
connected with USB.

If I could very easily and robustly work out what web method was going
to be called (beyond just parsing the URL - doable but slightly flaky,
I suspect) I would put the authorization rules in an XML form
somewhere, akin to how servlets work. Unfortunately I can't see any way
of finding out what method is going to be called programatically before
it *is* called. I may well have missed something though...
A bigger question is is it ok to couple the authentication logic with
transport? This depends largely on your requirements, but in general, HTTP
digest authentication for web services is a dead-end as are all
transport-based authentication schemes. They won't do if you want to
authenticate over other transports, over multiple hops, or have support for
WS-Security. Again, WSE would be the real answer here.
For other situations, you're absolutely right. In this case, a
transport authentication mechanism is fine, although I'd prefer not to
couple the *authorization* mechanism in there.

We're abusing web services in a few ways to make the bandwidth more
reasonable, as this is going over GPRS. Some calls have to be made with
HTTP POST rather than SOAP for that reason.
(*) I made a quick experiment with the following code in the web method:

Context.Response.Clear();
Context.Response.StatusCode = 403;
Context.Response.StatusDescription = "Access Denied";
Context.Response.Write("<h2>Access Denied</h2>");
Context.Response.End();

but it just ends up returning error code 500 anyway with a
ThreadAbortException. Most likely the Web Service infrastructure in ASP.NET
does not like you trying to change the HTTP response from within the web
method.

I think it doesn't mind that - it's the call to End() which causes
problems, by throwing an exception. I'm not sure where it sets the code
to 200 though - if it does that after the web method has executed, I
could have problems. Ah well - I'll keep experimenting.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

Ah well - I'll keep experimenting.

Current solution seems to work. Each web method has something like:

if (!CheckRole (...)) return;
or
if (!CheckRole (...)) return null;

CheckRole looks like this:

bool CheckRole(string role)
{
if (!Context.User.Identity.IsAuthenticated)
{
Context.Response.StatusCode = 401;
Context.Response.StatusDescription = "Access Denied";
// Context.Response.SuppressContent = true;
return false;
}
if (!Context.User.IsInRole(role))
{
Context.Response.StatusCode = 403;
Context.Response.StatusDescription = "Forbidden";
// Context.Response.SuppressContent = true;
return false;
}
return true;
}

For some reason, suppressing the content makes the server hang - no
idea why yet. That's a slight pity, but not significantly problematic.

That all seems to work, and has the benefit of allowing anonymous
access for the service description. If anyone knows any way of
improving the above, or why it's awful and should be avoided like the
plague, do let me know :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too