Welcome to Microsoft .NET Framework 3.0 Community (NetFx3)

The .NET Framework is Microsoft's managed code programming model for building applications that have visually stunning user experiences, seamless and secure communication, and the ability to model a range of business processes.

Learn More...

Windows CardSpace Team Bloggers

Browse by Tags

All Tags » CardSpace » Windows Cardspa... » Architecture - WS   (RSS)

  • New Issue of the Architecture Journal: Article on "Claims and Identity, On-Premise and Cloud Solutions"

    The latest issue of the Architecture Journal is available for download here (I am breaking the news even before the rest of the pages are updated from issue 15 to issue16: see how much I care about you?;-)). What makes this especially interesting is that issue 16 is entirely dedicated to identity! I have to admit that I've yet to read most of the articles, but I've definitely went through 2 of them: One is an interview/profile with Kim Cameron. It's a nice read, and I am sure you'll enjoy to know more about Kim The other is an article from yours truly, titled "Claims and Identity, On-Premise and Cloud Solutions". It expands on this post , and rolls in various others Writing for the Architecture Journal is a big honor, as you can see from the list of high profile former contributors, and I am very grateful to Diego for having my article in this issue. Thanks man! And thanks also to Gianpaolo , with whom I had many deep discussions that helped me to keep the abstraction tangents to what i hope is an acceptable level :-) As usual, if you have feedback feel free to send it my way Read More...
  • Issuing smartcard backed managed cards... using Zermatt

    We are back! I hope you had fun with the STS tutorial I posted yesterday night ; here we move a step further and examine how to equip our STS with managed card issuance logic & UI. As anticipated, this is going to be MUCH faster. If you recall, in the last post I asked you not to delete the Default.aspx page that the new web site template created for you: we are going to put our card issuance UI there. At thsi point the visual studio project should look as follows: The only new element I added is the information card image information-card.png, which will be used as the background of the information cards we'll issue. Of course nothing prevents you to get all fancy and allowing the user to upload an image for personalization purposes, but here we want to be quick & dirty (well, at least quick ;-)). The little image is below, for your viewing pleasure. Time to add some UI. Let's open Default.aspx inn the designer and let's drag some controls. <% @ Page Language ="C#" AutoEventWireup ="true" CodeFile ="Default.aspx.cs" Inherits ="_Default" %> <! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> < html xmlns ="http://www.w3.org/1999/xhtml"> < head runat ="server"> < title > Untitled Page </ title > </ head > < body > < form id ="form1" runat ="server"> < div > Managed Card Generator < br /> < br /> Card name: < asp : TextBox ID ="txtCardname" Read More...
  • Setting up a quick & dirty STS which supports smartcard backed managed cards... using Zermatt

    Just back from vacation. The tan barely started to fade, and here I am already playing with the new shiny toy :-). Did you experiment with Zermatt by now? As Kim mentions the samples (and the documentation) are an excellent way to start, and I am sure that blog posts & tutorials will soon start mushrooming here and there in the blogosphere: here I begin my humble contribution with my first technical post about Zermatt . I had *absolutely* no hesitations when deciding which scenario I should tackle first: an active STS which handles requests backed by smartcards . I received asks about from many segments (especially about eID management from governments and high authentication levels for finance) and pretty much from everywhere in the world (especially Europe and Asia): I am really delighted to finally have a chance to give you something about that scenario that you can compile in visual studio, as opposed to the usual whiteboard sketches :-) Before we dive into the code, let me disclaim the disclaimable: as usual, the code you see in this blog is just an example and is by no mean production ready code. My purpose here is to introduce you to new ideas, so I favor readability and clarity over completeness If you consider the definition of best practices as "A technique or methodology that, through experience and research, has proven to reliably lead to a desired result" , I think I can safely say that there are no established best practices yet. Sure, there are some fixed points Read More...
  • Announcing the Beta release of “Zermatt” Developer Identity Framework

    Ahh, I’ve been looking forward for this post for a looong time. We just made available for download the bits of the Beta of “Zermatt” Developer Identity Framework . “ Zermatt ” is the codename of a .NET framework that helps developers build claims-aware applications to address challenging application security requirements using a simplified application access model. Let me expand a bit on that. If you want to develop applications that take advantage of claims & identity Metasystem goodness in general, Zermatt makes your life easier by providing base classes, controls but especially capabilities & a programming model that take care of most of the plumbing for you. Regardless of the role (IP, RP, subject) or the style (Active, Passive, “ Passive-Aggressive ”), Zermatt shields you from the sheer handling of protocols & tokens and provides you with a great model for externalizing your access logic. For my loyal readers and in general to whoever worked with tokens and cardspace in general, who stormed me with mails since the TechEd EMEA demo and even earlier: this means that we can finally retire historical samples like the SimpleSTS and the TokenProcessor class . Zermatt is a fully supported developer framework that gives you those capabilities and MUCH more. How much more? Below there’s a partial list of the goodies you get: · An HttpModule (the Federated Access Module, or FAM) that takes care of handling the token processing pipeline: fully extensible & web.config-urable, Read More...
  • How often should you ask for a token?

    On the Seattle-Paris flight. I've just posted the piece about validation-authentication-authorization , and i am a bit bothered by the fact that I was unable to delve into greater details for what concerns the authoriZation part. In particular, I'd like to address one of the misunderstandings which can derive from transporting verbatim the knowledge of Kerberos & "unattended" security in general to the world of user centered identity management. Some of you claimaniacs may find the stuff below pretty obvious: I do. But judging from some heated argument I had about this, it may turn out that it is not that obvious after all so it's worth to write it down. How often should your application ask for a token? It may seem a silly question, and you may be tempted to reply with the answer that my wife gets when she asks to her auntie how often she should turn the roast: "as often as needed". Not the most actionable answer, I'm sure you'll concur :-). As in good tradition, let's take few steps back and look at the bigger picture. When you sit at your workstation and log in your domain, if your local network uses kerberos you get your nice ticket granting ticket (TGT); from that moment on, every time you take a ride on your network carnival (access a share, a portal, a printer...) the network software takes care of using the TGT for getting a ticket for you, which is specialized for the resource you are accessing. Everything happens seamlessly, and the user is lulled in blissful ignorance Read More...
  • Validation, Authentication, Authorization: mangling tokens for your dark purposes

    Flying back from S.Diego, after attending a great edition of Catalyst. I should probably write down my impressions before they fade, like it happened with the IIW, but there's in fact something (only mildly related) that bugged me for quite some time and I just want to flush it out of my system before going in vacation (somehow I feel that my old time Italian friends would not appreciate me blabbering about tokens, especially if I do it with my mouth full of focaccia al formaggio :-)). Ok, the story is somewhat similar to the " credentials are not identities " and returning user woes discussed in the Tao of authentication : it's a matter of agreeing on the semantic of terms that in the pre-token era had a simpler meaning, but that today need a richer/more rigorous definition. In summary: in practice , what RPs and STSes are supposed to do with incoming tokens? The answer lies in asking ourselves why we asked for a token in the first place. Perhaps the RP wants to see if the subject is allowed to sign in and start a session; an STS wants to know if the subject is worthy of being issued with the token he is requesting; and again, the RP may want to verify the the user has the necessary rights for performing a certain action (one may argue that this is a generalization of the signin case; I sort of agree, but later I'll make things more complicated). Even if we'd live in a world fueled only by shared secrets, there would be different cases to handle. If the RP is a simple password-protected Read More...
  • Active, Passive and Passive-Aggressive

    Ahh, terminology: joy and sorrow of our kind. There are some expressions that are very catchy and we use all the time, but that do not always serve well the purpose of communicating our thoughts. Take the usage of "passive" in the context of identity management; we tend to use it every time a web browser is in the picture, but that can be extremely confusing: if you just mean "I am talking about a web app" but you audience understands "he is going to use WS-Federation", you can be sure that things will get messy pretty quickly. In fact when I use CardSpace with a web app I am riding a passive client, but I obtain my token via proper WS-Trust traffic (thanks to our friendly identity selector) and I shove it directly in the first POST I send, without following the gracious redirect dance that WS-Federation would require. That's what I like to jokingly call passive-aggressive :-) For the ones among you that are not super familiar with this space, after the pic I restate the same but with extra context. Almost 5 years ago we published WS-Federation 1.0. To quote Don , THE authority on the topic: WS-Federation extends WS-Trust to provide a flexible federated identity architecture with clean separation between trust mechanisms, security token formats, and the protocol for obtaining tokens. This architecture enables a reusable token service model and protocol to address the identity requirements of both web applications and web services in a variety of trust relationships. Trivializing Read More...
  • All your tokens are belong to us?

    Kim just posted a great piece about "an account this week describing an attack on the use of CardSpace within Internet Explorer". I won't add anything, because his post is just perfect as it is: I strongly suggest you go read it in its entirety . Here a quote: "Students at Ruhr Universitat Bochum in Germany have published an account this week describing an attack on the use of CardSpace within Internet Explorer. Their claim is to “confirm the practicability of the attack by presenting a proof of concept implementation“. I’ve spent a fair amount of time reproducing and analyzing the attack. The students were not actually able to compromise my safety except by asking me to go through elaborate measures to poison my own computer (I show how complicated this is in a video I will post next). For the attack to succeed, the user has to bring full administrative power to bear against her own system. It seems obvious that if people go to the trouble to manually circumvent all their defenses they become vulnerable to the attacks those defenses were intended to resist. In my view, the students did not compromise CardSpace." Read More...
  • Perspectives.on10.net: podcast interview with Jon Udell on identity & "Understanding Windows CardSpace"

    Jon Udell recently launched a new interesting format on the website perspectives.on10.net. Perspectives is a series of in-depth conversations with passionate innovators. Most work for Microsoft; some work elsewhere; all are advancing the state of the art in areas as diverse as robotics, digital identity, e-science, and social software. Information technology is the common thread, and Perspectives appeals to the technically-minded, but the show also aims to tell stories in ways that make sense to a wider audience. Each installment of Perspectives is delivered as an audio podcast, and supplemented by a partial text transcript. The first episode was an interview with two guys from the Robotics Studio team, Tandy Trower and Henrik Frystyk Nielsen. The quality of the interview is clearly top notch, the scope of the topics strategic & forward looking but still solidly rooted in technology: Jon's editing makes things flow beautifully, and the transcript is incredibly handy for speed readers & search engines. In short, I LOVE IT :-) Hence, it is with ill-concealed pride that I announce the subject of the second episode : it is a chat I had with Jon back in December , just days before the book came out. The casus belli was the book itself, that Jon was so kind to read in prerelease version, but we ended up talking about identity on a much wider sense. We touched on certificates versus managed cards, omnidirectional vs unidirectional identities, WS-*, openID... Jon is a *great interviewer*, Read More...
  • The Tao of Authentication (Part III - last)

    (continues from Part I and Part II ) Finally we've lined up all the elements we need for understanding how we can get rid of the 1-2-3 tyranny, and deal with our business requirements directly instead of relying on an old model that forces us to perform unnecessary steps and introduces artificial dependencies. For making sense of what I write in this post you *really* need to read part I and II as well; without the right context, some of those things could be badly misinterpreted. Sorry :-) Outsourcing user authentication As much as I'd like to think that everybody is super interested in authentication, reality is that you may care very little about it. Let's say you are hosting your own blog, and comment spammers harass you. You can make their life more difficult by adding an authentication step, that will ask your readers to sign in before being able to comment. That's not a perfect system, but you know... security is a ladder. If you discouraged 70% of the spammers, you already made a great job. Or did you? Now you need to set up the authentication system, and above all maintain it. That means handling lost passwords; attacks to your credentials store, which may (read: will) contain passwords (well, hopefully hash derivations) your users are reusing with websites which feature higher value transaction; and many other annoyances. The blog example is a bit extreme on the low value gamut, but there are many other situations in which owning direct credentials authentication may Read More...
  • The Tao of Authentication (Part II)

    (continues from Part I ) You can consider this post and the fine grained analysis we made in Part I as a down payment for grasping the implications we'll see in Part III, which I plan to post in few hours (almost done). I was planning to have just 2 parts, but it came out far too long and I need 3 :). Here we'll see a very general architecture that can support the traditional authentication practice we described so far. Let me refresh your memory with those few key points we established last time: When we feel the need of authenticating users before giving access to our application, usually that's because we need the answer to some questions in order to execute correctly the service we are offering The question "are you a returning user" can be verified directly by using some mechanism, such as asking to the user to submit credentials . For almost all other questions we need to get an answer that satisfies us without a chance of verifying it directly in-band (messy, but if you read part I you'll understand) When we authenticate a user in "traditional" way, we essentially do three distinct things at the same time: We answer the question "are you a returning user?" by verifying the credentials We link the credentials to a profile in our archive We "dehydrate" that profile, and we use its content for answering our other questions We'll now review what are the architectural components that we customarily use for traditional authentication, that is to say what do we need for performing Read More...
  • NoSSL sample: a class for checking signatures of tokens sent to the RP in clear HTTP

    In short: I show a simple class that checks the signature of self issued tokens sent on a normal HTTP connection (as opposed to HTTPS); the same class takes care of generating a UniqueID and giving access to claims. It basically covers for the NoSSL case the core functions that TokenHelper offers for the SSL case. Today for few hours I found myself living in the early 90s. I agreed with Mario to meet at Victor's , the only place where coffee meets the bar of the Italian community here in Redmond, but he wasn't there. I did the obvious thing, I called his mobile: instead of connecting with him, I talk with his wife: she tells me that he forgot the phone at home, and he was already out. That happened all the time before everybody had a cell (for my circle of friends in Italy, that means '98), but now? Luckily I had my UMPC in the borsello, so I pulled it out and fired up Visual Studio. Few days ago we were chatting about the fact that we have no samples that work without HTTPS: the TokenHelper assumes that the incoming token is encrypted, which is not the case in the NoSSL scenario. It seemed engaging enough to fill the wait... so I wrote a little proof of concept that shows how an RP could handle a token sent in clear. Remember the long post I made in September about the same topic? There I was making the point that while the content of the token may now be visible (at least in the selfissued case, the one I will consider in this post), the way of authenticating the caller is unchanged: Read More...
  • The Tao of Authentication (Part I)

    From time to time it's healthy to challenge the assumptions, and look at (allegedly) familiar things with new eyes. Few weeks ago I had to do just that with the idea of authentication : I wanted to shake a bit an audience of architects, and make them * think* about the problem instead of relying on the stereotypes they had about it. Judging from the evals I've got, it worked :-) if you want to give it a try, check in at the door what you already know on the subject and come to play! The Tao of Authentication authentic being actually and exactly what is claimed from M-W When I say "authentication", what do you think of? No, I don't mean you identirati people, put your hands down; I mean what's the intuitive idea in the collective imagery. The typical answer you get from a generic audience is something like "it's when you check the identity of the user before giving access". That sounds in line with what traditionally happens as of today, but we'll see that there's more than meet the eye. Why do we authenticate, whatever that means? Simple. During the execution of the service we are offering we need the answer to some specific questions: the authentication phase is one of the ways in which we obtain the answer to those questions. Too abstract? Let me give you some notable examples. Questions Looks different from my usual messy sketches, eh? :) Well, that's a sample of my slides style. Some says they're too busy, some likes them... pick your camp. But I digress. Here we see our usual Read More...
  • Mike jumps on the OpenID Foundation board of directors

    Good news everyone! Our very own Mike will represent Microsoft on the OpenID Foundation board of directors, which to me seems a natural choice given all the work he has done in that space (for example, this ). Wait a minute, a Microsoft representative in the OpenID Foundation?!? If that surprises you, that means you didn't get the news : Google, IBM, Microsoft, Verisign and Yahoo joined en masse the OpenID board of directors. The future is now people! Read More...
  • CardSpace and Financial Services: HaWaNeDo with Figlo!

    Few months ago I made a little tour of Europe , and (among various places I visited) I went to spent some quality time in Amsterdam. Here I had the pleasure of spending some time with Albert van den Broek , CGO of Figlo : Albert is an excellent host, and during a nice dinner at a typical Dutch restaurant he explained to me the vision behind one of their new products. I am not very deep in financial considerations, so I will probably explain this in the wrong way (for which I apologize in advance): in any case, you can always go to their website and take a look for yourself. The point is that personal finance is an incredibly important aspect of our lives, and yet a surprising amount of people (including me) knows nearly nothing about how it works (reminds me of the fact that I've learned the function of carbohydrates and proteins only when I was already at college. crazy!). This is bad, because without a sense of how you choices today affect your situation tomorrow it is very hard to get to your objectives. Their point is, it doesn't have to be like that! They believe that presenting the situation with the right tool, such as a streamlined process backed by the right UI metaphor, anybody can take informed decisions and make actual steps toward his wishes (early retirement, college funds, similar stuff). They also have a very catchy name for the procedure, HaWaNeDo (Have, Want, Need, Do), which always helps in end user products. The day after I met with part of their board and Read More...
More Posts Next page »

Copyright © 2007 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us