Re: Storage of Client Certificates
- From: <jason.chen@xxxxxxxxxxxxxxxxx>
- Date: Thu, 15 Sep 2005 10:38:56 -0400
Hi William,
I guess the idea of using SCT comes from how SSL works, using the cert
to transmit the shared private session key and both sides use the session
key to encrypt request and response going forward. but this method can only
ensure the identity of the server, because you only have the certificate of
the server. you can not identify the client, so anyone can access your data.
your mentioned in your last sentence, the user will be authenticated
with a password, that means both server and client will have to agree on a
password and share that information, isn't this a bad thing to do, and it
breaks the PKI?
-Jason
"William Stacey [MVP]" <staceyw@xxxxxxxx> wrote in message
news:OLU9LIbuFHA.2624@xxxxxxxxxxxxxxxxxxxxxxx
> WSE has some nice ways to handle this, and you could hard code all this
> yourself, but then your recreating the wheel in a lot of respects. First,
> you only need one cert - the server's cert. This contains the RSA public
> key and you already will have the matching RSA private key protected on
the
> server somewhere (i.e. container, file, etc). The cert is really only
> needed to provide proof to the "client" who it is talking to and not some
> man-in-the-middle. Otherwise, you could just do this with just a self
> generated RSA key (I have some examples of doing this if you did not want
to
> use certs). The client starts with an authentication request. The cert
is
> used during Key exchange to generate a private session key on both sides.
> The way WSE surfaces that key is with security tokens - a good one being
the
> Security Context Token (SCT). WSE has a built in way to get a SCT using
> your cert (and the public key in that cert). Once you have a SCT, the
cert
> is out of the picture on both sides. Now all encryption and signing of
> messages can be done with the SCT for the rest of the session (because the
> SCT on both sides have the same SessionKey that is used for encryption).
> When the client sends a signed message to WSE service, WSE can now verify
> that message was signed by a user that "knows" the same session key as the
> SCT cached on the server. Then you create a helper method on your Web
> service such as AccessAllowed() or something (you can do in policy too I
> think.) Each web method that requires security will call this method as a
> first step, passing the SoapEnvelope to it. The helper method then
verifies
> the message was at least signed and that it was signed by an SCT that has
> been Authenticated (i.e. the user authenticated in first step with a
> password.)
>
> --
> William Stacey [MVP]
>
> <jason.chen@xxxxxxxxxxxxxxxxx> wrote in message
> news:ejhBryWuFHA.3628@xxxxxxxxxxxxxxxxxxxxxxx
> >I think so, I've tried that also, successfully. basically client will
send
> > their public key alone with the request, so you read it out from
> > SoapContext, and use it to encrypt the response. the downside of this
is,
> > any user that has your public key will be able to consume your
webservice.
> > if you think about it, your webservice is no longer 'secure', it's like
> > opening to public now. if you do not restrict what users can access your
> > webservice, then why go through the hassels protecting a public
webservice
> > at the first place?
> >
> > I think this brings up another question I have, what is the best
practice
> > in
> > order to restricted your webservice accessible to a set of known users?
if
> > you have a list of public keys from your clients, how do you figure out
> > which public key to use when your webservice received a request? best
> > approach I can think of is maintaining a list of trusted public key
> > identifiers in your config file, and make sure the public key in the
> > request
> > is among one of them. how do you guys think?
> >
> > -jason
> >
> > "RobertP" <RobertP@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> > news:60B28679-3E0C-44B5-9260-2B7EA919F697@xxxxxxxxxxxxxxxx
> >> To send an encrypted response back to the client, I would need their
> > public
> >> key.
> >>
> >> I guess I would not have to store their public key if they send the
> >> public
> >> key to me with their request?
> >>
> >> Thank You,
> >>
> >> Robert
> >>
> >> "Pablo Cibraro" wrote:
> >>
> >> > No, only if you identitfy your clients through public keys.
> >> > In this case, maybe, using a UsernameToken is a better idea. You can
> >> > use
> > a
> >> > UsernameToken to identify clients and a X509 certificate to protect
the
> >> > messages.
> >> > With this solution, your clients must have a public key and you only
> > need a
> >> > private key in the server's certificate store.
> >> >
> >> > Regards,
> >> > Pablo Cibraro
> >> > www.lagash.com
> >> >
> >> > "RobertP" <RobertP@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> > news:1A8ABB9F-00A4-453A-A156-7D2AFAED2E6E@xxxxxxxxxxxxxxxx
> >> > > If I have 5,000 users of my web service, I need to have 5,000
public
> > keys
> >> > > in
> >> > > my server's Certificate Store?
> >> >
> >> >
> >> >
> >
> >
>
>
.
- Follow-Ups:
- Re: Storage of Client Certificates
- From: William Stacey [MVP]
- Re: Storage of Client Certificates
- References:
- Storage of Client Certificates
- From: RobertP
- Re: Storage of Client Certificates
- From: Pablo Cibraro
- Re: Storage of Client Certificates
- From: jason.chen
- Re: Storage of Client Certificates
- From: William Stacey [MVP]
- Storage of Client Certificates
- Prev by Date: Re: what certificate to buy from Verisign ?
- Next by Date: Re: Storage of Client Certificates
- Previous by thread: Re: Storage of Client Certificates
- Next by thread: Re: Storage of Client Certificates
- Index(es):
Relevant Pages
|
