rammic

Does the CardSpace client respect the RequireClientCertificate attribute for the Security Policy HTTPToken assertion I've set the policy on my IDP to require it, though the client fails on the connection to the STS (apparently because a client certificate is not offered).




Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rammic

Any guidance on this yet Getting a quick yes/no would be sufficient.

Another question- No matter how I modify the policy, I cannot get the Cardspace client to respect the SignedParts directives. It seems to sign elements without respect to the policy. Am I missing something All I'm trying to get it to do is sign the MessageID header.

Code Snippet

<sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body/>
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>


It all seems to fall on deaf ears.

Thanks!






Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rakeshb

No, cardspace does not support RequireClientCertificate=true. The client can authenticate based on the the credential mechanism specified in the managed card. You can use certificate based client authentication when IDP is configured for message security based on mutual certificate and managed card file has UserCredential section with X509V3Credential.



Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rakeshb

Did you see a Signature section in the RST It might be that the channel is configured to encrypt the signature; in that case you will not be able to see it in RST (instead there will be an EncryptedData whose CipherValue will have the actual signature).

Are you using WCF for the STS





Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rammic

I am aware of (and use) the X509V3Credentials authentication. But when you have a corporate policy regarding the use of mutual SSL for all web interfaces, this creates a problem. And it's not all that large of a stretch to use the certificate specified within the .crd file as a SSL client certificate as well. Consider it a feature request. Smile

I have evaluated the entirety of the RST, and the client seems to invariably sign the wsa:To and the wsu:Timestamp.

Here's what I receive from the cardspace client:

Code Snippet

<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
<a:MessageID>urn:uuid:94f1b2f5-0773-496a-b33f-e879021b6a74</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1" u:Id="_1">...</a:To>
<o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" s:mustUnderstand="1">
<u:Timestamp u:Id="_0">
<u:Created>2007-03-16T19:02:37.971Z</u:Created>
<u:Expires>2007-03-16T19:07:37.971Z</u:Expires>
</u:Timestamp>
<o:BinarySecurityToken u:Id="uuid-89637bff-4ea3-4a9a-a73b-9fabefd02d1a-10" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">...</o:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference URI="#uuid-89637bff-4ea3-4a9a-a73b-9fabefd02d1a-10"/>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>



Despite the above cited policy regarding SignedParts (and variations thereof), this signature scheme seems to always be used.




Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rakeshb

I am able to get the signature properly.

Can you provide the entire policy/wsdl Maybe the signed parts xml fragment is not being tied to the Issue operation in wsdl





Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rammic

I'd rather not post the entire WSDL for simplicity's sake, but I will if we still can't figure it out. Until then, here are the relevant portions:

Issue Operation:

Code Snippet

<wsdl:operation name="Issue">
<wsp:PolicyReference URI="#issue_policy"/>
<soap12:operation soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue" style="document"/>
<wsdl:input>
<wsp:PolicyReference URI="#issue_input_policy"/>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<wsp:PolicyReference URI="#issue_output_policy"/>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>



Issue Policy:

Code Snippet

<wsp:Policy wsu:Id="issue_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body/>
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>






Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

dandrievsky

Rammic,

As I understand you want to use client SSL cert on transport level. Seems Cardspace doesn't involve cert/key referred by card as client's SSL credential.

If you are considering X509 auth type the simplest way IMHO - to use HTTPS(only server) for message security and client's X509 cert as SupportingEndorsingToken for message integrity and authentication.





Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rammic

Thanks for the reply.

I'm aware how X509 integrates within infocards. My issue, however, is that many corporate network policies require the use of mutual SSL for user-facing services (including my own). My intent was to determine if the Windows Identity Selector supported this, or offer it as a feature request in a future version. With access to the full certificate, using the identified cert for client SSL should be feasible.

With that resolved, my concern now is getting the selector to respect the SignedParts policies that it retrieves. I have only been able to get signatures on the wsu:timestamp and the wsa:to headers, which appear regardless of the defined policy. Has anyone been able to get this working properly If so, a snippet of the WSDL would be helpful.




Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rakeshb

Here's the policy I used for X509 auth using Transport security:

Code Snippet
< xml version="1.0" encoding="utf-8" >
<wsdl:definitions name="TestSecurityTokenService" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:i0="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">
<wsp:Policy wsu:Id="TestSecurityTokenService0_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
<sp:EndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
<sp:SignedParts>
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>
</wsp:Policy>
</sp:EndorsingSupportingTokens>
<sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
</wsp:Policy>
</sp:Wss11>
<sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:MustSupportIssuedTokens/>
<sp:RequireServerEntropy/>
</wsp:Policy>
</sp:Trust10>
<wsaw:UsingAddressing/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy wsu:Id="TestSecurityTokenService0_Issue_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:EndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<mssp:RsaToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never" wsp:Optional="true" xmlns:mssp="http://schemas.microsoft.com/ws/2005/07/securitypolicy"/>
</wsp:Policy>
</sp:EndorsingSupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsdl:import namespace="http://schemas.xmlsoap.org/ws/2005/02/trust" location="http://localhost:30123/ wsdl=wsdl0"/>
<wsdl:types/>
<wsdl:binding name="TestSecurityTokenService0" type="i0:IWSTrustContract">
<wsp:PolicyReference URI="#TestSecurityTokenService0_policy"/>
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="Issue">
<wsp:PolicyReference URI="#TestSecurityTokenService0_Issue_policy"/>
<soap12:operation soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
<wsdl:fault name="RequestFailedExceptionFault">
<soap12:fault name="RequestFailedExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="InvalidScopeExceptionFault">
<soap12:fault name="InvalidScopeExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="NotImplementedExceptionFault">
<soap12:fault name="NotImplementedExceptionFault" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="Renew">
<soap12:operation soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renew" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
<wsdl:fault name="RequestFailedExceptionFault">
<soap12:fault name="RequestFailedExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="NotImplementedExceptionFault">
<soap12:fault name="NotImplementedExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="InvalidScopeExceptionFault">
<soap12:fault name="InvalidScopeExceptionFault" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="Validate">
<soap12:operation soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validate" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
<wsdl:fault name="InvalidScopeExceptionFault">
<soap12:fault name="InvalidScopeExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="NotImplementedExceptionFault">
<soap12:fault name="NotImplementedExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="RequestFailedExceptionFault">
<soap12:fault name="RequestFailedExceptionFault" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="Cancel">
<soap12:operation soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Cancel" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
<wsdl:fault name="NotImplementedExceptionFault">
<soap12:fault name="NotImplementedExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="InvalidScopeExceptionFault">
<soap12:fault name="InvalidScopeExceptionFault" use="literal"/>
</wsdl:fault>
<wsdl:fault name="RequestFailedExceptionFault">
<soap12:fault name="RequestFailedExceptionFault" use="literal"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TestSecurityTokenService">
<wsdl:port name="TestSecurityTokenService0" binding="tns:TestSecurityTokenService0">
<soap12:address location="https://<machine>:31001/SoftX509"/>
<wsa10:EndpointReference>
<wsa10:Address>https://<machine>:31001/SoftX509</wsa10:Address>
<Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MI...I=</X509Certificate>
</X509Data>
</KeyInfo>
</Identity>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>





Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rammic

Thanks for the input, rakeshb.

Your WSDL isn't anything that I wouldn't expect. As I said before, I'm getting a signature from the selector, just not the one that I want. Have you tried to change the SignedParts policies to have it sign some other header, say MessageID I consistently get the wsa:to and wsu:timestamp fields signed regardless of my policy, so your policy doesn't prove anything for me. I tried using your policy and changing it myself, but I still get the same behavior.





Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

rakeshb

Sorry, I meant to post a different policy which had the additional fields in signed parts.

In your policy, can you try adding the signed parts assertion to the issue_input_policy instead of issue_policy





Re: Windows CardSpace (InfoCard) CardSpace Mutual SSL Authentication

Don Isenor

Was this resolved I am having the same problem -- no matter what I do to the security policy for X509V3Credential, CardSpace will not sign anything in the RST except the header Timestamp -- the SignedParts directive is simply ignored. This is definitely Not Good, as it makes the RST vulnerable to replay attacks. Has anyone got an example of a security policy that causes CardSpace to sign, say, the Body of a X509V3Credential RST Or is this a CardSpace bug

Please note, this has nothing to do with this thread's original question of mutual SSL authentication -- which I am not using -- but with the follow-up question of the ignored SignedParts element.