addddddddddddd

studying Simple STS. In particular UsernamePasswordCredential as authentication with STS but I have problems to understand how it works.

In the sample Infocard Profile V1 the credential are sent in clear text over HTTPS.

While in the simple STS they are encrypted somehow and sent via http with Ws-security. Actually the RST sent to STS by CardSpace is something like this.

Can some explain Does it mean that UsernamePasswordCredential, all in all, is not that bad.

In trying to understand the XML below i suppose that th shared key is encrypted with the public key of STS and the shared key is used to encrpyt the credential. Whicj is good.

<e:EncryptedKey >
<KeyInfo xmlns="
http://www.w3.org/2000/09/xmldsig#">
<oTongue TiedecurityTokenReference>
<o:KeyIdentifier >lJc67q3hq27XC6WNNPO0rsqY5lo=</o:KeyIdentifier>
</oTongue TiedecurityTokenReference>
</KeyInfo>
</e:EncryptedKey >


<cBig SmileerivedKeyToken u:Id="_1" >
<oTongue TiedecurityTokenReference>
<o:Reference URI="#TheUri"></o:Reference>
</oTongue TiedecurityTokenReference>
<c:Nonce>
<!-- Removed -->
</c:Nonce>
</cBig SmileerivedKeyToken>

<EncryptedData>
<oTongue TiedecurityTokenReference>
<o:Reference URI="#_1"></o:Reference>
</oTongue TiedecurityTokenReference>
</EncryptedData>
<oTongue TiedecurityTokenReference>
<o:Reference URI="#_1"></o:Reference>
</oTongue TiedecurityTokenReference>
<EncryptedData>
</EncryptedData>



Re: Windows CardSpace (InfoCard) UsernamePasswordCredential - credential encrypted

blowdart

Part of the MEX endpoint functionality (WS-Trust) is to tell the selector what encryption is available for use. The username and password are sent as part of the encrypted portion of the request for token.

What (I believe) happens is that the selector produces a symmetric key with which it encrypts the request. This key is protected and encrypted using the public key of the STS. It doesn't encrypt the whole thing using public/private as that's an expensive computational process to unencrypt. This is all part and parcel of how WS-Secure works.

(Someone correct me if I'm wrong here!)




Re: Windows CardSpace (InfoCard) UsernamePasswordCredential - credential encrypted

rakeshb

When https is used, the channel between sts and cardspace utilises the transport security mechanism. So the entire RST including the username/password is encrypted to sts through SSL.

When WS-Security is used, the transport used is generally http and hence the message has to be secured at WCF level using the mechanism of EncryptedKey and DerivedKeyTokens.

Choosing between http/https is a STS decision and both are secure.





Re: Windows CardSpace (InfoCard) UsernamePasswordCredential - credential encrypted

addddddddddddd

Thanks to both for the answer.

So UsernamePasswordCredential is a pausible use for autentication with a STS in corporate realm since the STS choose WS-Sec

What are the potential drawback of UsernamePasswordCredential in this case





Re: Windows CardSpace (InfoCard) UsernamePasswordCredential - credential encrypted

Toland Hon - MSFT

Having the users to actually type in a username and password.

//Toland




Re: Windows CardSpace (InfoCard) UsernamePasswordCredential - credential encrypted

addddddddddddd

Well, at least the credential are unique. In a corporate scenario UsernamePasswordCredential are good. The other option I see is using a smart card wich asks for a pin. I dind't understand if kerberos is/how applicable.





Re: Windows CardSpace (InfoCard) UsernamePasswordCredential - credential encrypted

blowdart

addddddddddddd wrote:

Well, at least the credential are unique. In a corporate scenario UsernamePasswordCredential are good. The other option I see is using a smart card wich asks for a pin. I dind't understand if kerberos is/how applicable.



Well if you're inside the corporate LAN kerberos will present (effectively) their NT login details without any need for the user to type in a password or insert a smartcard. Of course arguably you could do away with Cardspace then anyway