Using CardSpace<\/STRONG> to secure a Web Application…, that sounds interesting… We can also use CardSpace for securing WCF-Services for SOA application, but I leave that for another posting. :-). <object type=”application\/x-informationcard” name=”xmlToken” id=”xmlToken”> <\/SPAN><\/FONT><\/FONT><\/SPAN><\/P>\n <\/SPAN><param name=”tokenType<\/B>” value=”urn:oasis:names:tc:SAML:1.0:assertion” \/> <\/SPAN> <\/SPAN><\/FONT><\/FONT><\/SPAN><\/P>\n <\/FONT><\/SPAN><\/P>\n <\/SPAN><param name=”requiredClaims<\/B>” value=”http:\/\/schemas.xmlsoap.org\/ws\/2005\/05\/identity\/claims\/givenname http:\/\/schemas.xmlsoap.org\/ws\/2005\/05\/identity\/claims\/surname http:\/\/schemas.xmlsoap.org\/ws\/2005\/05\/identity\/claims\/emailaddress http:\/\/schemas.xmlsoap.org\/ws\/2005\/05\/identity\/claims\/privatepersonalidentifier” \/><\/FONT><\/FONT><\/SPAN><\/P>\n <object\/><\/FONT><\/FONT><\/SPAN><\/P>\n On the other hand, if we use a \u2018XHTML binary behavior’, it would be something similar to:<\/P>\n <!DOCTYPE html PUBLIC “-\/\/W3C\/\/DTD XHTML 1.0 Transitional\/\/EN” “http:\/\/www.w3.org\/TR\/xhtml1\/DTD\/xhtml1-transitional.dtd”><\/FONT><\/SPAN><\/P>\n <html xmlns=”http:\/\/www.w3.org\/1999\/xhtml” xmlns:ic><\/FONT><\/SPAN><\/P>\n <head><title>My Web-Site<\/title><\/FONT><\/SPAN><\/P>\n <link xhref=”App_Themes\/site_styles.css” mce_href=”App_Themes\/site_styles.css” rel=”stylesheet” type=”text\/css” \/><\/FONT><\/SPAN><\/P>\n <\/FONT><\/SPAN><\/P>\n <ic:informationcard<\/B><\/FONT><\/FONT><\/SPAN><\/P>\n <\/SPAN>id=’infocardBehavior’<\/FONT><\/FONT><\/SPAN><\/P>\n <\/SPAN>name=’infocardBehavior’<\/FONT><\/FONT><\/SPAN><\/P>\n <\/SPAN>style=’behavior: url(#default#informationCard)’<\/FONT><\/FONT><\/SPAN><\/P>\n <\/SPAN>issuer=’http:\/\/sts.labs.live.com\/trust\/InfoCard’<\/FONT><\/FONT><\/SPAN><\/P>\n <\/SPAN>tokenType=’http:\/\/docs.oasis-open.org\/wss\/oasis-wss-saml-token-profile-1.1#SAMLV1.1′><\/FONT><\/FONT><\/SPAN><\/P>\n <ic:add claimtype=’http:\/\/schemas.microsoft.com\/ws\/2005\/05\/identity\/claims\/privatepersonalidentifier’ optional=’false’ \/><\/FONT><\/SPAN><\/P>\n <\/ic:informationcard><\/FONT><\/SPAN><\/P>\n <\/head><\/FONT><\/SPAN><\/P>\n Take into account that usually, you need something more than just single auto-assigned information cards. If you really want to authenticate, you need to do it against any user credentials repository, right?. Well, it depends of our environment, but usually we\u2019ll have two typical ways of ‘how to authenticate’:<\/P>\n http:\/\/msdn.microsoft.com\/msdnmag\/issues\/07\/04\/identity\/<\/A><\/SPAN><\/P>\n How to Use Windows CardSpace with Internet Explorer 7.0<\/STRONG><\/P>\n http:\/\/msdn2.microsoft.com\/en-us\/library\/aa395199.aspx<\/A><\/P>\n
For a Web Application, we need to implement CardSpace within the Login and registration page, because we\u2019ll use it as an Authentication method.
So, let\u2019s suppose we have a registration page called Registration.aspx. We\u2019ll have to embedded \u2018something\u2019 into the HTML so the browser can know how to trigger CardSpace secure environment (the credentials selector). So, what can it be?. Well, we\u2019ve got at least two choices:
– A.- The CardSpace ActiveX Control<\/STRONG> which defines the requirements for our CardSpace implementation.
– B.- An \u2018XHTML binary behavior<\/STRONG>‘ for CardSpace<\/STRONG> describing the information card requirements. I’d use this option for non-IE browsers, like FireFox<\/EM>, etc.
In either case, we\u2019ll have to describe what are the InformationCard requirements. The two most important parameters are:
– Token Type<\/STRONG>: It tells to CardSpace user interface to prompt only with cards that represent this type of token.
– Claims<\/STRONG>: Claims that must be passed in the security token containing the user\u2019s identity. In this case, we require just \u2018required claims\u2019, but a user could also choose to send optional claim information as well, so it will also provide things like name, surname, address, or any other type of claim.
If we use a CardSpace ActiveX Control<\/STRONG>, it would be something like:<\/P>\n
A. – Use auto self assigned information cards and then, when the user is registering itself, we can create a Membership user, so, we can associate the card-id<\/STRONG> with the Membership user id<\/STRONG> we’ve just created.
B.- The second way is, of course, involving an ‘Identity Provider<\/STRONG>‘ in our system, using a STS<\/STRONG> (Security Token Service<\/EM>) which will be the external authority or ‘Identity Provider<\/STRONG>‘ assigning security tokens (any kind), and then, the Relying party<\/STRONG> (your web application) should also authenticate that security token agaist any type of user credentials repository (Active Directory Federation Services<\/EM>, Membership<\/EM>, or any other kind).<\/P>\n
So!, it is not a really complicated thing, but you have to consider different choices and getting the best from different worlds (HTML, Script and .NET executing at the server).
Read the following articles for a deeper scuba-diving in CardSpace:
Secure Your ASP.NET Apps And WCF Services With Windows CardSpace<\/STRONG><\/P>\n