Editor's note: Welcome to .NETRocks Conversations, excerpts of conversations from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month's excerpt is from show 667, with .NET security expert Michele Leroux Bustamante, chief architect of IDesign and co-host with Patrick Hynds of the LockDown weekly Internet talk show, on the complexities of implementing federated security in applications.
Carl Franklin: So we're talking about identity again.
Richard Campbell: I don't want to be sad about it, but I'm just frustrated. When is identity going to catch on, Michele?
CF: Or has it, and we just don't know?
Michele Leroux Bustamante: Here's the deal. It's catching on, there's no question about that. In fact, it's catching on so much that people really want it, but they're frustrated because they don't get it or it's too much work to do it still. This is just the nature of the beast in some respects, but it's the nature of the beast because of protocols. If you remember back in 2000, there [were] no tools, and it was really difficult. Even getting a single call to work, you had to get the namespaces and the XML, and people still didn't know how to do that. So it was a struggle. And then we got all these tools that made a simple request easy, but then we jumped into all these standards on top of SOAP that helped us with, well, primarily it started with security. How do I send a username and a password so that everybody understands the same way, so that we can stop reinventing the wheel on passing usernames and passwords between platforms?
RC: Right.
MLB: Because otherwise everybody has got a role of their own, and then nobody agrees. Then that moved to certificate security and securing the actual transfer of the username/password without SSL, so that we would have a message security when you're signing and encrypting on both ends. Then that moved into some things like secure sessions, so we don't authenticate every call, and now we have a session, and there's a way to pass the session material. Then we move from that to federation, so security on its own. It has had a whole series of things happen up until about 2005 when identity federation first came to be in a stack form. Back then you really fought to get that thing working, and the tools worked amongst themselves, but the interop story had to be kind of flushed out. Now that the interop story is flushed out more or less, and I think everybody agrees on the protocol, the challenge still remains that people have to understand how do I design my system to work with this. There's still a lot to understand, and if you're not an identity expert, then guess what? That's really hard to approach.
RC: There also seems to be some simplification going on, the more REST-based approaches, OpenID, OAuth.
MLB: And those were there first.
RC: Were they really?
MLB: Well, OK. I shouldn't say they were there before the spec, and I don't actually know exactly the timeline, I mean in terms of when OpenID and OAuth started. But I would say they've been evolving now also for a long time, at least in parallel. It's just that REST maybe wasn't quite as popular, and now REST is really, really moving forward for a lot of reasons.
RC: Sure.
MLB: You look at OData, you look at ways to get and stream media quickly. I mean, who wants to go through a SOAP layer for that. I don't.
RC: Yeah.
MLB: It's complicating our services out on the back end because now it's starting to look like you could do everything with REST, and the only thing that REST is missing from the basic level is we still don't have that whole proxy generation, rapid generation of prototypes tool. But when it comes down to building a production system, I don't really use those anyway. I still would just get the contract and write my own base proxy and then reuse that. So I'm not really losing a lot if I'm going to go all in REST.
RC: Yeah.
MLB: I'm not saying I'm now a REST proponent over SOAP because I still usually work with SOAP-based systems in an enterprise. But I would definitely argue that we're going to see a lot more of that, and the security story around REST is much simplified because you're talking HTTP headers, you're talking a way to pass an authorization header that tends to still have a federated token of sorts. It's just it's not using a symmetric security, so you might argue that using the SOAP-based mechanism for federation is more secure at its core. But how secure do you need to be, I guess. And I don't mean that in the wrong way. I guess I mean username/password over SSL has worked for a lot of people for a really, really long time.
CF: That's always been my point.
MLB: You want the complexity, and the extra security, and the complexity that comes with that that makes it hard for my development team to maintain this without calling the shower or somebody else like her, because that's really hard.
CF: Right.
MLB: And I'm not trying to talk myself out of work either.
CF: No, no, no.
MLB: Because I help a lot of people but...
CF: It's a really good point. You really can't do this without help of an architect who understands it.
MLB: Yeah, you can't.
RC: But it also means that your average run-of-the-mill application still has minimal security features.
MLB: Yeah. I mean, I guess you're right. You're going to be, again, username/password over SSL is what we would call good enough to get the job done. And then the minimum I would argue I still want federation. I don't think federation is a waste at all. I think even despite the complexity, we all still really need that because it really sucks to have to build into your app all the different ways to authenticate a user, whether it be Windows, or username/password, or certificate, or you're using other authorization or authentication proxies like a SightMinder or Forefront. We want to still be able to support all those things, but not to have our app know about them. My WCF service shouldn't care about Forefront, it shouldn't care about the type of credential that was used. It should just get a token from somewhere that we trust, and I still maintain that is absolutely simplifying our life. We need the token to be easier to deal with.
CF: Do you think the real public e-commerce sites—I'm thinking Amazon, maybe even eBay, places that do a lot of volume, do you think if they were to require identity, the identity system that users have certificates or identity cards or ID cards or whatever we call them, that it would be a hamper to business? Or is it possible to support them optionally?
MLB: Well, this is another very good question. If you're building a new site that you want to be as big as Amazon or what-not, and all you already have is a site like Amazon, you still have the same challenge in both cases, and that is you want your users to not be deterred from using your service.
RC: Right.
MLB: So how can you do that? You give them option. You don't force them to federate. You don't force them to use Facebook, or Yahoo!, or any other identity provider on the web. You say, look, if you want, here, you can put a username/password here. But if you've already got Facebook, or Yahoo!, OpenID, or a Google ID, or Windows Live, then here you go. You pick the one you want is what they're saying.
CF: Right. So what I'm saying is, is it possible to implement a federated identity authentication and not require it of your users. If so, does that defeat the point?
MLB: Well, actually, the way I would do it is I would have my own identity provider, so I would still be—in theory, my website would be pure. It's always getting a token from my identity provider, I would call it a Security Token Service. I don't care if it's REST-based or not, so let's not differentiate between sort of the OAUTH path or the SOAP mechanism, the different protocols like XAML 2.0 and WS Federation on the browser. So it doesn't matter which of those protocols you use. You're still saying, look, my app is going to get a token, and I'm going to redirect over there to get you authenticated. If you want to use Facebook, or Google, or Yahoo!, or Windows Live, or if you want to use your own username/password in our system, well, we'll authenticate you on our system over there. So you don't see it, but you still redirect it somewhere else to do the authentication, so internally my app is pure and just receiving a token always from my STS. That's the way I would do that. Now you could in theory use Access Control Service in the cloud for that because they do provide access to Google, Yahoo!, Facebook, and Windows Live built-in, but you don't have to write that code, which is really sweet.
CF: OK.
MLB: But the thing that they won't do is they don't provide a username/password store. So I mean they do, but it's not something you'd use for real production system, so that's not its intent. Its intent is as a claims transformation engine. So its job is to just be the hub, and you redirect to your STS from there.
CF: You see that on websites where you can check out using our secure server or sign in, authenticate using Windows Live or whatever. You give the option to the user.
MLB: Right, right. Yeah, you do. Well, and checkout is probably a little different because they're deciding also how you're going to pay, and so sometimes they might be sending you to PayPal, for example. But yeah, I mean, no matter what, [the] app should look at federation, and I think it means to get it easier. But the question is what protocols do we use for that and how do we make it so the customers have nothing or need to know how much they had to implement that. The customer being the developer.
RC: It's still awfully hard to make any of this stuff work.
MLB: Yeah, and I think it's easier with the REST stuff because it's just a simple token format, a simpler thing to use your format to look at and parse, and then you just do it over SSL. So you're not dealing with all this certificate security.
RC: What about Access Control Service? Is it part of Azure?
MLB: Yeah. So Azure AppFabric has Access Control Service, and like I said its job is to be a claims transformation engine and hub in the cloud for federating with other STS[s]. So where it really shines today is in if I was building a web app and I wanted to provide a service so that my customers could login to Windows Live, or Facebook, or Google, or Yahoo!, and I wanted to give them all of those options potentially, then I can do that by just using the Access Control Service—bam, I'm done. So what am I getting out of that? What I'm getting is a token from Access Control at my app that says, yes, they authenticate it and here's their name identifier, which is this unique ID for my app only for that user. So every app gets its own name identifier, which means you and I can't collude on the same user because we won't get the same identifier.
RC: Interesting.
MLB: Right. So we can't say you went to that gaming site and also you go to this thing because you wouldn't know.
RC: This is part of Azure AppFabric. Do I have to have a cloud app to use it?
MLB: No, no. I mean, you can use that and have an on-premise[s] app, or you can use that and have an app in the cloud. But ideally, if you're going this route, you're probably hosting an app on the Internet one way or another that you want users that come from the community, you want the social network automatically available to your application. Not all apps need that. If I'm building a business app and you're signing up to use my app as a service and it's a concrete business app, I probably don't want Facebook to know you've been to my app. It's none of their business.
CF: Yeah.
MLB: Facebook is getting way too much information.
CF: It's a private app.
MLB: Right. So I'm going to have my own user store with credentials, and I'm probably not going to let you login with one of those Facebook, Windows Live things because I don't want that to be connected because I don't want them to have information about when you access my app—how often and so forth, because in theory, especially with Facebook, they have that information.
RC: Right.
MLB: So it's an interesting issue.
RC: Yeah, it's an interesting issue. At the same time I like the idea that here's a tool that lowers the bar for giving the ability to do identity for your application.
MLB: Yeah. So what I would do is I would have my app, my STS, I build some sort of custom STS that's just for our users, and then if I wanted to support all the Facebook, Googles, I'm not going to write that code. That's a waste of my time, so I'm going to get an Access Control account, and if you want to login with one of those, I'm going to send you there to do it and I'll pay the fee for that if I really want those users because I don't want to write that code.
RC: So I'm only paying for Azure when people use that service even if it's just running on my site.
MLB: Right. And there's a fee. Those transactions cost a fee. It's a fraction of a penny for a single authentication request.
RC: Right.
MLB: So I don't think that's going to put me over the top, and frankly if it is, it's a good problem to have. That means I have a lot of users, and maybe I can afford a developer to write that code.
CF: Absolutely.
MLB: Or I'm making enough money that I don't care for paying that cost, it's no big deal. So let's call it a web app if you're doing browser-based federation, like I'm in a website and I'm redirected, or a service like a WCF service equivalent whereby its job is to authenticate and issue a token saying you were authenticated and provide the claims that identify you and possibly other information about you in that system.
CF: Yup. That's the crux of it.
MLB: Right. So whether again that's using any number of protocols, and that's one of the problems we have, there's no one protocol for federation and there never will be, probably.
RC: No.
MLB: There are just preferences. So WS Federation and WS Trust are the oasis vendors that have come along and are standardized within Windows Identity Foundation with Microsoft. So if you're building Microsoft apps, you're probably using that by default. But a lot of people use XAML 2.0, and XAML 2.0 is not going away anytime soon. So, for example, Active Directory Federation Services v2 supports XAML 2.0 as well, and that's important because it's a very strong standard. For example, folks in the Java community might lean toward that instead of federation, and folks using earlier versions of .NET that don't support WIS use XAML 2.0 because you can get components to support that. Then you've got OAuth, which is, again, it's got some unique capabilities related to interacting with mobile devices and such, but basically you could use it for REST-based, and that's the idea behind the Access Control Service. It just uses a very simple token, if you wish. But you tack it onto the authorization header, and your REST-based services can process that. And there's no SOAP, so it's really easy, and you can whip up your own version of that pretty easily, too, to support the protocols.
CF: SOAP was all about interoperability for things that are very complex, and everybody seems to have implemented things over REST, and some of which bump up against some of those complex things. Are the WS standards still necessary and still used for interoperability?
MLB: Yeah. That's a really, really good question, and I think one of the things that's interesting to me is if you look at the progression of standards, everybody touted, oh, well, with SOAP you can do reliable messaging, which is a way to do retries as the connection fails. That's a great thing to have. It creates a little overhead in the first call. But if you really, really want to make sure that you can overcome hiccups in communication without having to start from the beginning again, that can be really useful for sending chunks of data like images and things like that. It's useful, it's important, but you know what? It seems like nobody cares, and so they're not using it.
There's much more! You can find the full interview on the .NET Rocks website.
You know, I would still recommend it in certain environments, but a lot of people are just saying, look, if it fails I guess I'll deal with it and I'll just retry. It's there for a good reason, and there are people using it, and I still would say it's a good thing to use if you can apply it, but people just don't care enough. And then transaction is a whole other discussion because doing transactions across services could be a really useful thing, and certainly we love it when we're doing MSMQ. But just crossing those service boundaries means you have to have the DTC, you need to have all these moving parts in the IT side, and this is really tough stuff to troubleshoot. It doesn't just work. So it's better to push the transaction down as low as you can.
Richard Campbell and Carl Franklin (both Microsoft Regional Directors) are the voices and brains behind .NET Rocks! (www.dotnetrocks.com). They interview experts to bring you insights into .NET technology and the state of software development. They’re more than dry technical interviewers—they have fun!
