Re: How can WSE2 work in the real world?
From: Hervey Wilson [MSFT] (herveyw.nospam_at_nospam.microsoft.com)
Date: 10/08/04
- Next message: Hervey Wilson [MSFT]: "Re: WSE 2.0 & SAML"
- Previous message: Oliver Roth: "WSE 2.0 & SAML"
- In reply to: Tim Haynes: "How can WSE2 work in the real world?"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 08 Oct 2004 10:33:26 -0700
Tim Haynes wrote:
> I must be missing something. From the examples I have seen, WSE really only
> seems to work sensibly if the user has an X.509 certificate, something which
> 99.9% of people do not have. It's fair enough for the server to have a
> certificate (as for SSL), but you can't expect this of every user.
>
>
>
> Kerberos tokens are useless as they only work within a Windows domain and
> won't work on Win2000 server (on which most networks run). Anyone know
> if/when MS will fix this?
WSE 2.0 Service Pack 2 later this year will improve the usability of the
KerberosToken by eliminating some of the privelege requirements. Of
course, the KerberosToken will still require either a Windows Domain or
integration with another Kerberos system.
>
> Usernames and passwords are the universal currency of identification, but
> user tokens only appear to work in WSE only if you use plain text (very
> dumb!) as hashed values need the server to have the plain text password for
> comparison (also dumb).
Reading the OASIS WSS UsernameToken Profile[1] and this entry (and
comments) on my blog[2] should give you some more background as to why
the product works in the way it does and some options. If using SSL is
reasonable, then it's reasonable to send plain text passwords over the
connection. More comments on this further down.
[1]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
[2] http://www.dynamic-cast.com/mt-archives/000065.html
>
> What I really need to do is something like:
>
> 1. In clear, the client asks the server for its public key and verifies it
> is signed by a trusted third party.
SSL does this. You could also implement a variation of the WS-Trust
protocol to achieve this. WSE2 has plenty of extensibility around
RST/RSTR exchanges to allow this. Alternatively, you could install the
server certificate at the client to bootstrap this process.
>
> 2. Encrypt a user token using this public key and send to server which
> authenticates the user.
This is fine. SSL will, of course, encrypt the entire channel.
>
> At this point, both parties have been identified and the user token could be
> used for signing or encryption
Possible, but not the most secure option. See below.
>
> OK so far, but it still requires the server to retain the username/password
> in memory (still not good!). The better option is probably to set up a
> WS-Secure conversation, for example:
>
> 1. In clear, the client asks a service token provider for its public key and
> verifies it is signed by a trusted third party.
Same as (1) above.
>
> 2. Encrypt a user token using this public key and send to service token
> provider which authenticates the user.
Same as (2) above.
>
> 3. Secure token provider sends back the session token which is used in
> subsequent communication and throws away the username/password.
>
This is WS-SecureConversation and is implemented in WSE2. The session
token (SecurityContextToken or SCT) carries a randomly generated key (by
default, a 128bit AES key). At the server, the SCT is linked back to the
"base token", in this case the UsernameToken, for authentication /
authorization purposes.
>
>
> Now this seems very sensible to me, but am I way off track? Is there a
> better way? Can this be done? How? Anyone got any examples? Code and/or
> policy based?
See the SecureConversation samples in the product. You could modify the
SCT issuing part to run over SSL and then access to the services using
the issued SCT could run without SSL. Chris Keyser[3] also has a series
of articles about using an SCT in a web-farm scenario and you might
build on this to have a single SCT issuer accessed over SSL. This would
issue an SCT from a plaintext password, the SCT would be extended to
carry authentication information. The SCT could then be used directly
against one or more services without the need for SSL.
[3] http://blogs.msdn.com/chriskeyser/
-- This posting is provided "AS IS", with no warranties, and confers no rights.
- Next message: Hervey Wilson [MSFT]: "Re: WSE 2.0 & SAML"
- Previous message: Oliver Roth: "WSE 2.0 & SAML"
- In reply to: Tim Haynes: "How can WSE2 work in the real world?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
