Re: Is WSE 3 and Kerberos useful for securing services at the method level?

We've written a custom PolicyAssertion / SoapFilter pair of subclasses that
grab the SecurityToken out of SoapEnvelope.Context.Credentials, create a
RoleProviderPrincipal if necessary, check IsInRole membership against roles
configured for the SoapEnvelope.Context.Addressing.Action and ultimately
populate the Thread.CurrentPrincipal.

The SoapEnvelope SecurityTokens will be populated by the WSE pipeline, so
you're not just limited to Kerberos.

We've found it to be very useful, as we have lot's of different services on
the same ASMX.

HTH,

Howard Hoffman

"Pablo Cibraro [MVP]" <pcibraro@xxxxxxxxxxx> wrote in message
news:uq4s3ktGHHA.1468@xxxxxxxxxxxxxxxxxxxxxxx
Hi Eric,

Your supposition is correct at certain extent. You can use the Windows
Principal available in the kerberos token to check permissions at method
level.
Another solution is to extend the Kerberos assertion provided by WSE to
set the CurrentThread.Principal property with the principal available in
the kerberos token. Once, you do that, you can use PrincipalPermission to
set permissions at method level.

Regards,
Pablo Cibraro.

"Eric" <someone@xxxxxxxxxx> wrote in message
news:unLH6XiGHHA.3976@xxxxxxxxxxxxxxxxxxxxxxx
I am designing some services that I am thinking would be good to secure
using Kerberos as we have an intranet setup. It is pretty clear how you
secure a user at the service level, but I'm curious as to how one would
use Kerberos to secure at the method level. Say I have an AD group named
"MyApp" that allows a user to access the service. I'd also like to have
another group "MyAppAdmin" which gives a user access to more methods on
the service than the vanilla user would have.

I havent seen anything so far to suggest that the WSE helps you in my
scanario beyond providing you with the account name of the user so you
can use code to check for methods you want extra security on, whereas the
service level authentication is pretty much built in. Is that a correct
assesment?

Thanks,
Eric






.

Relevant Pages

  • Re: kerberos authentication
    ... I am trying to secure a WS using WSE 3.0 and kerberos. ... I used the "WSE 3.0 settings" from VS2005 with my own WS. ... WS/IIS and AD on the Windows 2003 server ... Kerberos is a NETWORK authentication protocol, that is, it only works across networks, your client and server are running on the same server, that means Kerberos won't be used, more, there is probably no authentication handshake needed, the client may be already authenticated and have his token cached by the local LSA (provided he's Kerberos ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: WSE 2 and impersonation
    ... We don't plan on working with kerberos. ... it seems that WSE expects you ... have it extract the information it needs in order to impersonate. ... > 2 client machine to be able achieve that. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Is WSE 3 and Kerberos useful for securing services at the method level?
    ... Principal available in the kerberos token to check permissions at method ... Another solution is to extend the Kerberos assertion provided by WSE to set ... Once, you do that, you can use PrincipalPermission to set ... service level authentication is pretty much built in. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: WSE 2 and impersonation
    ... If you are looking to create an interoperable web service, ... For our particular solution, Kerberos is ... >> a Kerberos ticket that allows the Web service consumer (running on ... >> When the message is received by WSE, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: WSE 2 and impersonation
    ... If WSE 2.0 is installed on Windows ServerT 2003 or Windows® XP with Service ... Kerberos has the benefit of being an open security standard, ... thus promoting interoperability between WSE-enabled Web service applications ... won't work for messages sent from server to client as the client has no way ...
    (microsoft.public.dotnet.framework.webservices.enhancements)