Re: WCF security advice (and clarification) needed
- From: "Tiago Halm" <thalm@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 12 Mar 2008 00:34:03 -0000
No, its not possible.
When authenticating with Windows/Kerberos (say
http://foo.mycompany.com/mypage.aspx or
nettcp://foo.mycompany.com/mysvc.svc) you'll be asking your KDC (with a TGT
on your hand) to give you a service ticket for the SPN
HTTP/foo.mycompany.com, or MyService/foo.mycompany.com. The KDC validates
your TGT and looks for the account with that SPN registered. On finding one,
it creates a service ticket with your information and with an
"authenticator" which only a process whose identity is that account can
decrypt. You, the client, resolve the foo.mycompany.com hostname within your
own DNS. Having the IP address you then make a SOAP call (within HTTP or
TCP/IP) with that ticket as the security token. Upon receiving the request,
the service will look into the token, decrypt it and be able to see that the
ticket is valid, the ticket is from you and the ticket is to access
"himself" and will then process your request.
Tiago Halm
"Anders Jensen" <AndersJensen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:101ACD39-4302-4759-8E2C-E34DB81BD7EA@xxxxxxxxxxxxxxxx
Hi Tiago
First, thank you very much for the answer, it answered almost everything I
needed to know. For our application I think Windows/Kerberos is
appropriate,
I am just wondering about one thing. How is the servers identity ensured
when
using Windows/Kerberos? I mean, wouldn't it be possible for some malicious
party to spoof the servers identity when the server is not authenticated
through some 3rd party (CA or STS)?
Cheers
"Tiago Halm" wrote:
Anders,
There are two parties participating in a security scenario, the server
and
the client. Let me give you a simple example for HTTP parlor. I'll then
follow up with WebServices specifics.
When you use HTTPS (SSL) in a webserver, you're using a server
certificate
and whenever a client connects to that webserver he's in fact validating
the
server is who he says he is by following the certificate chain of the
server
certificate. The webserver is in fact presenting the client with the
public
key allowing the client to send information encrypte with that public key
which only the webserver can decrypt with its private key.
When/If the client uses a client certificate, he'll be authenticating
himself to the server, and the server will use the same methodology to
validate the credentials. He'll then authorize the client the way it sees
fit.
Now, all this HTTP talk mentioned a single security token supported by
the
HTTP protocol - X.509 certificates. HTTP supports other authentication
modes, like Negotiate (SPNEGO/NTLM), NTLM, Digest and Basic
Authentication.
WebServices present us with a richer protocol able to handle multiple
security tokens, the ability to use multiple security tokens in a single
message and the ability the secure different parts of the message with
different security tokens for different recipients. The security tokens
supported are - Username Token (similar to Basic Auth), Kerberos Token
(similar to SPNEGO), X.509 (similar to certificates) and SAML.
When you create a WebService you define the binding (basicHttpBinding,
wsHttpBinding, netTcpBinding, NamedPipeBinding, others ...). All these
bindings support the latest WS standards (except basicHttpBinding which
supports only some of the standards) and allow you to specify the
security
settings of your choosing.
When selecting security settings you must choose how the server will
authenticate to client and how the client authenticates to the server.
Only
some combinations are possible, ex:
client (Username) + server (X.509)
client (X.509) + server (X.509)
client (Kerberos or Windows) + server (Kerberos or Windows)
(more)
You also have the option of choosing where (with constraints) the
security
tokens are set, the message (SOAP) or the transport protocol
(HTTP/TCP.IP)
SAML is a different beast, where you have 3 participants. The client
contacts an STS (issuer) to get a SAML authenicating himself with any
combination of the above, and presents the SAML to the server on every
operation allowing the client to present himself in a uniform way to any
server able to validate the SAML.
Anyway, I think you already have a lot to chew on.
You can browse examples of the WebService security scenarios here:
http://msdn2.microsoft.com/en-us/library/ms730301.aspx
Finally, choosing your security settings can be (almost) independent of
the
chosen binding. That is one of the beauties of WS-* :)
By the way, with Windows (Kerberos) on both sides (client and server) the
communication is already encrypted and signed because Kerberos already
makes
use of session keys/tickets.
hope it helps
Tiago Halm
"Anders Jensen" <AndersJensen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E682602A-F336-45AF-868E-D321CC2A8C7B@xxxxxxxxxxxxxxxx
Hi
After a couple of days of trying to get to grips with WCF i need some
advice
on how to implement security.
We will be using the NetTcpBinding and message-level security, the only
thing is, we are not completely sure what actually happens per default.
If
I
set SecurityMode.Message, per default, Windows authentication is used
on
both
server and client? If we assume that the server is in fact who it
claims
to
be, is this communication then secure in both directions (encrypted and
signed)?
Let me put it in another way. If I had a public/private-key pair on
both
the
server and client I would encrypt with the public-key and decrypt using
the
private-key in both directions which means that given both client and
server
are who they claim to be, I have secure communication. When using
Windows
authentication, some kind of token is created? How does this work (in
simple
terms)?
If I then add a CA-signed certificate on the server to verify the
servers
identity to the client, how does the scheme then change? I assume that
Windows authenication is still used on the client side?
If I then again add ClientCredentials (Username and Password) on the
client,
can I then use those for authorization without altering the way the
server
and client communicates?
We are having some trouble getting an overview of WCF security so if
this
is
basic stuff, please bear with me.
Cheers
.
- References:
- Re: WCF security advice (and clarification) needed
- From: Tiago Halm
- Re: WCF security advice (and clarification) needed
- From: Anders Jensen
- Re: WCF security advice (and clarification) needed
- Prev by Date: Re: WCF security advice (and clarification) needed
- Next by Date: Borland c++ client.
- Previous by thread: Re: WCF security advice (and clarification) needed
- Next by thread: Borland c++ client.
- Index(es):
Relevant Pages
|
