Secure conversation will certainly work, but it may be overkill for what you
are trying to accomplish. It sounds like you may only be looking for digital
signing, without encryption. Have you thought about setting up HTTP/S on
your app server, and thereby requiring that all calls to it must be run over
HTTP/S? This approach may be more expensive than your own homegrown secure
conversation solution, if you decide to purchase a certificate. But if you
are using Windows Server 2003, it can serve as a Certificate Authority, and
you can generate your own trusted certificates.
A separate approach would be to cache a username token in the Web service,
so that at least you don't have to keep regenerating it, although you will
continue to need to assign it.
Given the various options, I would say the best choices are secure
conversation, versus HTTP/S. But this is just my opinion.
Jeffrey Hasan, MCSD
President, Bluestone Partners, Inc.
-----------------------------------------------
Author of: Expert SOA in C# Using WSE 2.0 (APress, 2004)
http://www.bluestonepartners.com/soa.aspx [quoted text, click to view] "SA" <informatica@freemail.nl> wrote in message
news:e02y5ABcEHA.1144@TK2MSFTNGP11.phx.gbl...
> Yes, you can use WS-SecureConversation, which is supported by WSE 2.0.
>
> I recommend you start with the sample provided in the WSE 2.0 Quickstart
> samples. It shows how a service consumer can request a
SecurityContextToken
> and then use that token to sign and encrypt messages. It also shows how a
> service can provide a RequestSecurityTokenResponse automatically if the
> RequestSecurityToken is valid.
>
> Regrettably, the sample (as many others) make heavy use of X.509
> certificates. If you want to stick to just usernames and passwords, check
> out the recent thread "Removing x509 certs from SecureConversationCode
> sample, Is this the right way?"
>
> HTH,
>
> --
>
> Sven
>
>
> "Johnny Cash" <meaneyedcat@hotmail.com> wrote in message
> news:e04c3215.0407220735.5d041ba9@posting.google.com...
> > I am building a Web application that makes calls out to our app server
> > via Web Services calls.
> >
> > The code-behind pages of my ASPXs call delegate classes that are
> > responsible for actually making the Web Service calls. Right now, in
> > my delegate classes, each method call that calls a web service
> > instantiates a WSE class, sets the username/password, and then invokes
> > the actually method call.
> >
> > Is this the best way architecturally to do this? I don't really like
> > the idea of constantly having to set the user/name password for each
> > WSE method call. Is there a best practice around this type of set up?
> >
> > Thanks!
> > BCOT.
>
>
