A lot of people have asked me, “But how does a user GET a managed Information Card?” They are referring, if you are new to this discussion, to obtaining the digital equivalent to the cards in your wallet.
I sometimes hum and ha because there are so many ways you can potentially design this user experience. I explain that technically, the user could just click a button on a web page, for example, to download and install a card. She might need to enter a one-time password to make sure the card ended up in the hands of the right person. And so on.
But now that production web sites are being built that accept InfoCards, we should be able to stop arm-waving and study actual screen shots to see what works best. We'll be able to contrast and compare real user experiences.
Vittorio Bertocci, a colleague who blogs at vibro.net, is one of the people who has thought about this problem a lot. He has worked with the giant European Etailer, Otto, on a really slick and powerful smart client that solves the problem. Otto and Vittorio are really on top of their technology. It's just a day or two after Vista and they have already deployed their first CardSpace application – using branded Otto cards.
Here's what they've come up with. I know there are a whole bunch of screen shots, but bear in mind that this is a “registration” process that only occurs once. I'll hand it over to Vittorio…
The Otto Store is a smartclient which enables users to browse and experience in a rich way a view of Otto's products catalog. Those functions are available to everyone who downloads and installs the application (it is in German only, but it is very intuitive and a true pleasure for the eye). The client also allows purchase of products directly from the application: this function, however, is available only for Otto customers. For being able to buy, you need to be registered with http://www.otto.de/.
That said: while buying on http://www.otto.de/ implies using username and password, the new smart client uses Otto managed cards. The client offers a seamless provisioning experience, thanks to which Otto customers can obtain and associate to their account an Otto managed card backed by a self issued card of their choice.
Let's get a closer look through the screens sequence.
Above you see the main screen of the application. You can play with it, I'll leave the sequence for adding items in the shopping cart to your playful explorations (hint: once you're chosen what to buy, you can reach the shopping cart area via the icon on the right end.
Above you see the shopping cart screen. You can check out by pressing the button circled in red.
Now we start talking business! On the left you are offered the chance of transfering the shopping cart to the otto.de web store, where you can finalize the purchase in “traditional” way. If you click the circled button on the right, though, you will be able to do go on with the purchase without leaving the smartclient and securing the whole thing via CardSpace. We click this button.
This screen asks you if you already own an Otto card or if you need to get one. I know what you are thinking: can't the app figure that out on its own? The answer is a resounding NO. The card collection is off limit for everybody but the interactive user: the application HAS to ask. Anyway, we don't have one Otto card yet so the question is immaterial. Let's go ahead and get one. We click on the circled button on the left.
This screen explains to the (German-speaking) user what is CardSpace. It also explains what is going to happen in the provisioning process: the user will choose one of his/her personal card, and the client will give back a newly created Otto managed card. We go ahead by clicking the circled button.
Well, that's end of line for non-Otto customers. This screen allows the user to 1) insert credentials (customer number and birthdate) to prove that they are Otto customers and 2) protect the message containing the above information with a self issued card. This is naturally obtained via my beloved WS-Security and seamless WCF-CardSpace integration. Inserting the credentials and pushing the button in the red circle will start the CardSpace experience:
The first thing you get is the “trust dialog” (I think it has a proper name, but I can't recall it right now). Here you can see that Otto has a Verisign EV certificate, which is great. I definitely believe it deserves my trust, so I'm going ahead and chosing to send my card.
Here there's my usual card collection. I'm going to send my “Main Card”: let's see which claims the service requires by clicking “Preview”.
Above you can see details about my self issued card. Specifically, we see that the only claim requested is the PPID. That makes sense: the self issued card will be used for generating the Otto managed card so the PPID comes in handy. Furthermore, it makes sense that no demographic info are requested: those have been acquired already, through a different channel. What we are being requested is almost a bare token, the seond authentication factor that will support our use of our future Otto managed card. Let's click “Send” and perform our ws-secure call.
The call was successful: the credentials were recognized, the token associated to self issued card parsed: as a result, the server generated my very own managed card and sent it back to you. Here's there is something to think about: since this is a rich client application, we can give to the user a seamless provisioning experience. I clicked “Send” in the former step, and I find myself in the Import screen without any intermediate step. How? The bits of the managed card (the famous .CRD file) are sent as a result of the WS call: then the rich client can “launch” it, opening the cardspace import experience (remember, there are NO APIs for accessing the card store: everything must be explicitly decided by the interactive user). What really happens is that the cardspace experience closes (when you hit send) and reopens (when they client receives the new card) without any actions required in the middle. If the same process would have happened in a browser application, this would not be achievable. If the card is generated in a web page, the card bits will probably be supplied as a link to a CRD card: when the user follows the link, it will be prompted by the browser for choosing if he/she wants to save the file or open it. It's a simple choice, but it's still a choice.
Back on the matter at hand: I'm all proud with my brand new Otto card, and I certainly click on “Install” without further ado. The screen changes to a view of my card collection, which I will spare you here, with its new citizen. You can close it and get back to the application.
The application senses that we successfully imported the managed card (another thing that would be harder with web applications). The provisioning phase is over, we won;t have to go through this again when we'll come back to the store in the future.
At this point we can click on the circled button and give to our new Otto Card a test drive: that will finally secure the call that will start the checkout process.
Here's we have my new card collection: as expected, the Otto card is the only card I can use here. Let's preview it:
Here's the set of claims in the Otto card: I have no hard time to admit that apart from “Strasse” and “Kundennummer” I have no idea of what those names mean :).
I may click on “Retrieve” and get the values, but at the time of writing there's no display token support yet: nothing to be worried about in term of functionality, you still get the token that will be used for securing the call: click the circled button for making the token available to WCF for securing the call.
Please note: if you are behind a firewall you may experience some difficulties a this point. If you have problems retrieving the token, try the application from home and that should fix it.
That's it! We used our Otto managed card, the backend recognized us and opened the session: from this moment on we can proceed as usual. Please note that we just authenticated, we didn't make any form of payment yet: the necessary information about that will be gathered in the next steps.
Also note that it was enough to choose the Otto managed card for performing the call, we weren't prompted for further authentication: that is because we backed the Otto card with a personal card that is not password protected. The identity selector was able to use the associated personal card directly, but if it would have been password protected the selector would have prompted the user to enter it before using the managed card.It definitely takes longer to explain it than to make it. In fact, the experience is incredibly smooth (including the card provisioning!).
Kim, here's some energy for fueling the Identity Big Bang. How about that? 🙂
That's great, Vittorio. I hear it.
By the way, Vittorio is a really open person so if you have questions or ideas, contact him.
Thanks for the illustrative walkthrough. However I am concerned when Mr. Bertocci writes that “Please note: if you are behind a firewall you may experience some difficulties a this point. If you have problems retrieving the token, try the application from home and that should fix it.” – hopefully home users have considered firewalls as well. Is there a known issue with certain firewalls blocking CardSpace – IdP interactions? (I have seen this with personal firewalls not recognizing the CardSpace component and treating it's attempts to establish outgoing TCP connections as suspicious, but I haven't heard what would cause firewalls to not accept outgoing WS*/HTTPS connections as used by CardSpace?
I also was a bit perplexed by that and will send this on to Vittorio for comment. Clearly it would be a non-starter if CardSpace couldn't be used behind a firewall. Unlikely, because a lot of people at Microsoft use it to go to my site, and I use it with a managed card run from my identityblog site.
Hello Mark, hello Kim.
The firewall issue is not related to CardSpace itself, but by a combination of implementation choices of Otto and the settings of certain firewalls. Let me give you further details on that.
When you implement an STS for supporting managed cards, you need to provide at least 2 endpoints: one, secured via WS-Security, will process the requests for token issuing (RST messages).The other endpoint will listen for WS-MetadataExchange, so that the policies associated to the STS can be readily acquired. For security reasons (if you are interested in the details we can drill down) such an endpoint must be secured via HTTPS. Now: in the Otto case, the WS-MetadataExchange endopint is exposed on a port that is different from the classical 443. It MAY happen that certain firewall will block all HTTPS traffic on ports different that 443. As a result, for this particular application and for certain firewall settings you may have issues. Let me restate the above: this is by no mean inherent to the use of CardSpace, it is the consequence of deployment decisions about your STS. If the WS-MetadataExchange endpoint is set on 443, the most common choice by the way, you don't have any problems. I hope that it clarifies, I will add this update direcly in the body of the original post. If it is still unclear, feel free to ping me: I will be happy to drill down further.
There also seems to be a problem using Cardspace behind an authenticating proxy. I keep on getting 407 errors. I've posted on the MSDN forums about this, but so far haven't had a useful reply.
Cheers
Matt
Hi Vittorio, Kim and Mark,
Sorry to come into this thread concerning the managed card demonstration, which I think looks very well thought out and crafted.
What I am more interested in, is your statement above concerning the mandatory use of HTTPS. I agree that the current implementation of CardSpace seems to require HTTPS, but why? I'm afraid I AM interested in the details, and so would be very grateful if you could explain this to me. “For security reasons” is an acceptable answer if there really is no other way to achieve what HTTPS gives you, but what is this? What can be achieved with HTTPS that cannot be achieved with what is offered by WS-Security? To drill down and explain this is something I'm very keen for someone within the CardSpace architecture community to do.
If, as is sometimes the case, HTTPS is not an acceptable protocol to be allowing through your firewall, is CardSpace still usable as an identity solution? Clearly, in many situations, trying from home is not an option!
In response to the question that started the thread, I believe the issue relating to firewalls/proxies is not just that the HTTPS port is blocked, but also that some Proxies / FWs require authentication prior to allowing users out. The ability of the user to leave the network therefore depends on the credentials that the CardSpace virtual desktop will use to authenticate to the Proxy. If this is the local system account, then clearly that will present problems. I'm afraid I don't know enough of the details to give you a definitive answer, but it does look like there may be some issues surrounding this.
Many thanks for any guidance you can give me on this issue.
Rui, this too is a very cogent post. I will bring this up to the main line and blog about the issues.
Hello Rui,
let me try to shed some light.
There are two different ways in which CardSpace mandates HTTPS.
The most common subject of conversation is about RPs in form of websites: in that case, CardSpace mandates the usage of HTTPS in order to secure the communications with the browser AND for facilitating the server authentication operations (that is to say, giving to the user clear clues about the identity of the server he's interacting with).
The matter discussed here, however, is not connected to websites: we are considering web services, and specifically STSes. As mentioned, the main endpoint of the STS is secured via WS-Security. The WS-MetadataEndpoint, however, is the way in which the STS advertises its policy requirements: if it would be protected by WS-Security itself, we would be imposing to potential callers prior knowledge of the policy that it would be used for securing the call! This is clearly a circular argument, and potentially a regression ad infinitum. Using HTTPS on the WS-MetadataExchange endpoint guarantees to the caller of the service that the policies exposed by it are TRULY the ones intended by the STS. The bottom line is that if we want to expose our policies in a dynamic fashion, without imposing any prior knowledge (or out of band communication) to the STS users, we have to bootstrap the communication in some secure manner: HTTPS is a valid mean of guaranteeing that anybody can receive the policy requirements ina secure fashion and with confidence that such policies are coming from the proper source. I hope that it clarifies 🙂
I will be happy to address further comments: however I am going to start a long conference where I speak in many sessions, hence I won;t be very timely. Bear with me, I will answer to everything as soon as I can 🙂
Cheers,
V.
I dont want to sound discouraging – but I log into your blog with two clicks. Otto, oy ve!! I gather the Germans are smarter than the rest of us – and that this experience it not targetting German grandmothers, but it does seem so much more complicated than your two click registration.
Is all this heavy lifting always mandatory for an eCommerce site? Worried.
Hello again Kim and Vittorio,
Thankyou for your responses to my post. I look forward to your discussions of this issue, Kim, as it is something that has been vexing me.
I am happy to focus firstly on the use of CardSpace in regards to web services (which I consider less problematic than Web sites, as it happens).
In terms of retrieving the policy, it would be perfectly possible to retrieve a policy that was digitally signed (using XML Dig Sig / WSS) with the same certificate that is used for establishing the HTTPS connection (key usage allowing, of course). The digital signature would ensure that the policy comes from the STS that the user is trying to connect to, though personally I do not even think that is necessary – a policy could be signed by another trusted party. By taking this approach, there would be no need for an HTTPS connection at all.
Let me explain: what needs to be established is TRUST. The recipient of the policy (in this case the CardSpace virtual desktop) needs to know that it can trust the policy before acting on it. If the digital signature is valid, then it can trust that it has not been altered (the specified “prevent policy tampering attacks” from “The Guide to Interoperating with the Information Card Profile V1.0”). If it trusts the signer of the policy, then it knows that it is a policy that it is prepared to accept and act on. There could certainly be a warning in the CardSpace UI if the Policy was signed by a party other than the issuer, but it could still be feasible to accept that signature, as long as the signing party is trusted.
This is the same as what is happening with HTTPS. The trust still exists prior to the receipt of the Policy – the UI still needs to have prior knowledge of the CA that issued an SSL certificate in order to trust that certificate. Admittedly an HTTPS connection could not be countersigned by a third party, but that is not an integral part of what I am suggesting. In my opinion, nothing is being added by the use of HTTPS, although I can see that in certain environments the dependency on HTTPS would be an unacceptable risk. There is nothing wrong with having HTTPS as an optional part of the architecture – I can see that it makes many implementation details more straightforward – it is the dependency (the MUST-ness) of the CardSpace infrastructure relying on HTTPS that I find unnecessary.
I hope that I have made the reasons for my reservations sufficiently clearly. If you would like my view on websites, then I will post that, but I would rather stick to the STS scenario for now.
I hope you enjoy your conference, and I look forward to your or Kim's response.
Bye for now,
Rui