“Geneva” Team Blog : .NET 3.5

CardSpace on FAT File Systems

CardSpaceBlog — Tue, 11 Dec 2007 05:07:10 GMT

The version of Windows CardSpace that shipped in .NET Framework 3.0 will not run when installed on a FAT file system. We’ve received a surprising amount of feedback (some of the earliest from Pamela Dingle) that customers are still using FAT file systems and this is causing problems. This was done because FAT doesn’t provide ACLs and therefore the files CardSpace uses for storing cards can be deleted or corrupted by malicious code running as the user. Since the store files are still double encrypted by both the user’s and the system’s keys, even on a FAT drive, user code cannot access the contents of the file and read the secret card information. Given the feedback we received, and that the cards are still protected against theft, we decided to make the changes and enable CardSpace (shipped with .NET Framework 3.5) on FAT File Systems. This change doesn’t have any side effect on the rest of the product so running CardSpace on partitions formatted with FAT or NTFS produces the same results.

This is a change intended to meet some customers’ demands but we still recommend the use of NTFS because it’s a more secure environment not only for CardSpace but also for all other files in the computer.

Rafael
Windows CardSpace Team

CardSpace support for Oasis WS-SX standards

CardSpaceBlog — Thu, 22 Nov 2007 06:40:00 GMT

The OASIS Web Services Secure Exchange (WS-SX) technical committee has published specifications for WS-Security extensions and policies to enable the trusted exchange of SOAP messages. Their effort resulted in the WS-SX specifications that include WS-Trust, WS-Security policy and WS-Secure conversation. This standardization of WS-Trust is good news. Gartner says that:

OASIS's ratification of two key standards means that Web services security has finally reached a level of maturity acceptable to many enterprises. This is a positive development for vendors and customers alike.

The ratification happened in March 2007 and support for these standards was one of the main changes included in the .NET Framework 3.5 release of CardSpace.

Overview of new WS-Trust specification

The OASIS WS-Trust is very similar to the one people have been using. The main differences are:

1. Returning the security token: a RequestSecurityTokenCollection element is used to return a security token in the final response.

2. SecondaryParameters: When a requestor inserts parameters into an RST request that come from a third party, for example a relying party policy, there is a potential for an attack. In the contributed request, both requestor RST parameters and third party RST parameters are mixed together as direct children of the wst:RequestSecurityToken element. This prevents an STS from differentiating between the RST parameters based on their source. Therefore, the STS trusts both kinds of RST parameters in the same way. This can open a potential attack vector because the third party is given control over the content of the RST message that the requestor sends to the STS. For this purpose, a new element wst:RequestSecurityToken/wst:SecondaryParameters was introduced, that acts as a bag for RST parameters introduced by a third party. This allows an STS to mitigate the attack by differentiating parameters originated by the requestor and parameters not originated by the requestor. Note that same element can occur as direct child of <RequestSecurityToken> as well as child of SecondaryParameters.

3. Bearer tokens: This trust version supports bearer tokens.

4. Namespace changes: A new namespace http://docs.oasis-open.org/ws-sx/ws-trust/200512 was introduced. This affects the URI for KeyType, RequestType and SOAP Action on the STS endpoint. For e.g., the symmetric key type is http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey in place of http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey.

5. Batch requests possible: In scenarios where multiple RSTs need to be sent, it is now possible to send them all at once using a RequestSecurityTokenCollection. This helps avoid multiple network round-trips. (Not a CardSpace scenario)

How does this all affect CardSpace?

First I would like to clarify that the CardSpace changes for the new WS-Trust version implement an additional feature. CardSpace will continue to support the previous WS-Trust specification (http://specs.xmlsoap.org/ws/2005/02/trust/ws-trust.pdf) having the namespace http://schemas.xmlsoap.org/ws/2005/02/trust.

If you have developed an STS or rich applications using the previous trust version, those will continue to work.

Which scenarios can leverage the new trust specification?

1. Managed card scenarios: An Identity Provider can choose to use the new trust version

2. A web service: Rich web services based on WS-* protocols can choose to use the new trust version. E.g., a Calculator web service built using WCF that uses CardSpace to secure its service endpoint.

3. Resource-STS: A resource STS can choose to use the new trust version. The Resource STS can serve either a website or a web service (as in previous point).

Note that the scenario involving a website asking for a self-issued card cannot leverage the new trust version.

CardSpace behavior when the new trust version is involved

1. Identity Provider: The Identity provider issues managed cards and generates token on demand. The card issuance is not affected at all. For token generation, following is the new behavior:

a. Policy retrieval: CardSpace determines the trust version used by the IP STS based on the policy. The policy needs to be expressed using the WS-SX version of security policy and use the Trust13 assertion to specify its WS-Trust capabilities. When using WCF for building the STS, use bindings such as WS2007FederationHttpBinding or CustomBinding with a security version like WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12 for the appropriate policy to be generated. Sample policy snippet looks like:

<wsp:Policy wsu:Id="policy">

    <wsp:ExactlyOne>

        <wsp:All>

            <ic:RequireFederatedIdentityProvisioning xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity"></ic:RequireFederatedIdentityProvisioning>

            <sp:SymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                ...

            </sp:SymmetricBinding>

            <sp:SignedEncryptedSupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                ...

            </sp:SignedEncryptedSupportingTokens>

            <sp:Wss11 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                ...

            </sp:Wss11>

            <sp:Trust13 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                <wsp:Policy>

                    <sp:MustSupportIssuedTokens></sp:MustSupportIssuedTokens>

                    <sp:RequireServerEntropy></sp:RequireServerEntropy>

                </wsp:Policy>

            </sp:Trust13>

            <wsaw:UsingAddressing></wsaw:UsingAddressing>

        </wsp:All>

    </wsp:ExactlyOne>

</wsp:Policy>

b. STS Contract: Due to the change in namespace, the contract will have to be modified accordingly. For e.g., when using WCF, the operation will be as below:

[OperationContract(

    Name = "Issue",

     Action = "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue",

    ReplyAction = "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal" )]

Message Issue(Message request);

c. RST parsing:

i. KeyType: Due to the change in namespace, the parsing of the KeyType will have to be modified to support the new URIs for symmetric, public, and bearer (no-proof) keys

ii. RequestType: Due to the change in namespace, the parsing of the RequestType in RST will have to be modified.

iii. Claims: The claims are always sent in the top-level RST body.

iv. SecondaryParameters: CardSpace will send the parameters it receives from resource (or Relying Party) as an xml blob within the SecondaryParameters. The secondary parameters are skipped in the following cases:

· The user chooses not to send optional claims. In this scenario, secondary parameters are omitted to hide this user decision

· The situation is such that no wsp:AppliesTo is being sent in the RST. In this scenario, secondary parameters are omitted so that IP does not get any identifying information about resource/RP.

Sample RST looks like:

<wst:RequestSecurityToken Context="ProcessRequestSecurityToken" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

<wsid:InformationCardReference xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity">

</wsid:InformationCardReference>

<wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity">

...

</wst:Claims>

<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>

<wst:SecondaryParameters>

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

<wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>

<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>

<wst:KeyWrapAlgorithm>http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</wst:KeyWrapAlgorithm>

...

</wst:SecondaryParameters>

</wst:RequestSecurityToken>

d. RSTR construction: The issue response has to be wst:RequestSecurityTokenResponseCollection (RSTRC). Within this RSTRC, a single RSTR is expected. In case the STS emits a RequestType in the RSTR, the URI to be sent needs to be changed as per the new namespace. A sample RSTR snippet looks like:

<wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">

    <wst:RequestSecurityTokenResponse>

        <wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>

        <wst:RequestedSecurityToken> ... </wst:RequestedSecurityToken>

        ...

    </wst:RequestSecurityTokenResponse>

</wst:RequestSecurityTokenResponseCollection>

2. Resource STS: A web service resource or a website can delegate the task of authentication/authorization to a resource STS. In such a scenario, the Resource STS will have to set up an endpoint to process the RST/RSTR similar to an IP STS. All the points mentioned for Identity providers are applicable in this case. The changes are in the RST parsing.

It is no longer assured that the typical properties like claims and keytype will always be a direct child of the top level wst:RequestSecurityToken element. The RST parsing code will have to look into wst:RequestSecurityToken/wst:SecondaryParameters in case it finds information missing from the top-level elements.

3. Web service: A web service can act as a resource in rich client scenarios. When such a web service uses CardSpace for authentication, it can potentially use the WS-SX trust version. The resource will have to express its policy using WS-SX version of security policy and use the Trust13 assertion to specify its WS-Trust capabilities. In case of WCF resource, you can use Ws2007HttpBinding, Ws2007FederationBinding or a CustomBinding with an appropriate security version like WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12 to accomplish this.

4. Token generated by self issued card: CardSpace in .NET Framework 3.5 understands the WS-SX standards. So when a self issued card is requested using a WS-SX based policy, the token generated will process and comply with the parameters like KeyType, KeySize, etc. expressed in the policy. A sample scenario where this is possible is a Web service or a Resource STS asking for a self-issued card.

5. Bearer tokens: Consider scenario of website asking for a managed card. Since browser is a passive client, it cannot do proof of possession. Hence, CardSpace v3.0 used the concept of KeyType=NoProofKey in scenarios like this. The WS-SX version of WS-Trust introduced concept of requesting bearer tokens to address such scenarios. A new KeyType value http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer is added. CardSpace in .NET Framework 3.5 will use this new URI value for the KeyType element in the RST when the IP STS is using the new trust version. Note that rich client support for bearer tokens is not implemented in CardSpace.

Mixed trust versions

Things can get confusing when different legs of the scenario use different trust versions. For example, consider the following scenario:

A web service or a website is requesting a token from Resource STS. This Resource STS is asking for a managed card. The IP STS uses WS-SX version of WS-Trust (Trust13). And the Resource STS uses older WS-Trust (Trust10). The RST that is received by the IP STS will have the policy of the Resource STS in its SecondaryParameters. But since these parameters will be in Trust10, the contents of the SecondaryParameters element will also be in Trust10.

<wst13:RequestSecurityToken Context="ProcessRequestSecurityToken" xmlns:wst13="http://docs.oasis-open.org/ws-sx/ws-trust/200512">

...

<wst13:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst13:KeyType>

<wst13:SecondaryParameters>

<wst10:KeyType xmlns:wst10="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</wst10:KeyType>

...

</wst13:SecondaryParameters>

</wst13:RequestSecurityToken>

This can complicate the parsing of RST. The Identity Provider will have to decide on an approach for such scenarios like not supporting it, or ignoring SecondaryParameters or parsing of parameters in Trust10 namespace.

Thanks!

Rakesh Bilaney

SDET, Windows CardSpace

All the bits to employ CardSpace without an SSL certificate are now available

CardSpaceBlog — Fri, 26 Oct 2007 09:24:00 GMT

Hi, my name is Tariq Sharif and I am a program manager in the CardSpace team. After we released CardSpace V1 we received feedback from hobbyists, early technology adapters and site owners that getting/setting up a SSL certificate is hard and it is not needed for some set of their scenario and that this is blocking them from accepting information cards on their sites. Based on this feedback, the feature team decided to remove this requirement for the .Net Framework 3.5 release.

In order to invoke Cardspace from a page that does not have an SSL connection you need two updated components. First you will need to install an updated browser specific extension that will work at an HTTP site. You can download the IE extension from here or if you have IE7 you probably already have it as part of the October security update. Second you will need to install an updated version of Cardspace that does the right thing when a website, the relying party, does not have a certificate. Latest version of Cardspace can be downloaded as part of .Net Framework 3.5.

You can read more technical details about this new functionally here in this post that Ruchi made a couple of weeks ago. Please feel free to drop us any comments on this, as we are always looking for feedback to help us refine this emerging technology.

Thanks,

Tariq Sharif

Program Manager

How Identity Providers can show custom error messages in CardSpace

CardSpaceBlog — Thu, 04 Oct 2007 20:47:00 GMT

Wouldn’t you like to show your users a custom error message instead of this generic one?

Now you can with the latest .Net Framework 3.5 release (Beta 2 as of this blog). Your Identity Provider can simply return a SOAP fault and CardSpace will display the Fault Reason Text. This feature is great because it enables you to present the user with help and support information such as phone numbers or URLs. Your error message can now look like this:

Your fault reason text can also be language specific. CardSpace will display the correct fault reason text based on the UI locale.

Frequently Asked Questions

What is the format of a SOAP message?

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">

<s:Header>

<a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>

</s:Header>

<s:Body>

<s:Fault>

<s:Code>

<s:Value>s:Sender</s:Value>

</s:Code>

<s:Reason>

<s:Text xml:lang="en"> In English …</</s:Text>

<s:Text xml:lang="es-ES">In Spanish …</s:Text>

</s:Reason>

</s:Fault>

</s:Body>

</s:Envelope>

Note that this SOAP message must be secured just like a typical application message. That is, it must contain the necessary Security headers (with all the necessary signature and encryption requirements based on the binding). CardSpace will only display secured fault messages. It will not display unsecured fault messages.

Can I present rich HTML information?

CardSpace will only display plain text messages.

How do I return a custom error message with WCF?

Your code snippet will look something like this:

using System.ServiceModel;

…

FaultReasonText defaultMessage = new FaultReasonText(@"Our record on file shows that you are not authorized to use this service. If you have forgotten your user name or your password, please visit

http://www.contoso.com/help for further assistance.

You can also call (123) 456-7890 to speak with one of our customer care representatives.", "en");

FaultReason reason = new FaultReason(defaultMessage);

throw new FaultException(reason);

The FaultReasonText has constructors that take the culture info (see http://msdn2.microsoft.com/en-us/library/system.servicemodel.faultreasontext.faultreasontext.aspx). The list of culture names is documented at http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo.aspx. You can even do something like this:

FaultReasonText defaultMessage = new FaultReasonText(@"The default error message", "en");

FaultReasonText spanish = new FaultReasonText("(In Spanish) Español", "es-ES");

List<FaultReasonText> reasonInDifferentLanguages = new List<FaultReasonText>();

reasonInDifferentLanguages.Add(defaultMessage);

reasonInDifferentLanguages.Add(spanish);

FaultReason reason = new FaultReason(reasonInDifferentLanguages);

throw new FaultException(reason);

There are a few caveats. Due to the way the WCF channel stack processes a SOAP message; the fault message will be sent as a secured fault message if you throw the FaultException in the following places:

1. Within the code path of ServiceAuthorizationManager.CheckAccessCore

2. Within the code path of the Identity Provider’s Issue operation.

If you want to show a friendly error message due to authentication failures, the above steps is not sufficient because the WCF channel stack will send back the exception as an unsecured fault message. Since CardSpace only displays secured fault messages, the user will not see the friendly message that you have sent back. Instead the user will see the generic version.

The workaround is to use the security extensibility points in WCF to delay throwing an exception until the WCF channel stack calls into the ServiceAuthorizationManager.CheckAccessCore. The steps below use the UserNamePasswordValidator as an example; the same principle applies to other types of validation as well:

1. Implement a custom UserNamePasswordValidator to validate the user name and password.

2. Implement a custom UserNameSecurityTokenAuthenticator to call your custom UserNamePasswordValidator. If the user name and password validation succeeds, return a custom IAuthorizationPolicy that will pull in other claims permitted for this user. If the password validation fails, return an invalid authorization policy. The job of this invalid authorization policy is to insert an “invalidusernamepassword” claim when called upon.

3. Implement a custom ServiceAuthorizationManager to check for the “invalidusernamepassword” claim in the AuthorizationContext. If it exists, throw your friendly FaultException message. If it does not exist, you can check the other claims to grant /deny access.

4. Wire up these customizations by implementing a custom ServiceCredentialsSecurityTokenManager and a custom ServiceCredentials. Then replace the ServiceCredentials on ServiceHost with the custom one.

For further details regarding the above (including code samples), do visit these resources:

· UserNamePasswordValidator

· Govind’s blog on plugging in a custom UserNamePasswordAuthenticator. Govind’s office, by the way, is on the same floor as mine. It was really convenient for me to walk over and ask him questions about how the security layer works in the WCF channel stack J.

· MSDN article on Custom Security Token Authenticator

· How to create a custom Service Credentials

Is there a sample I can play around with?

Brian on our team is working on samples right now. He’ll post it once the samples are ready.

Cool new feature, isn’t it. Do let us know how else we can help you build a better Identity solution.

Dedicated to your success,

Tak Wai, Wong

Software Design Engineer in Test

CardSpace Team