Hello everybody. Here we are in Sun's Santa Clara offices. We have two special guests with us. Would you like to introduce yourselves? Okay. I'm Pat Patterson. I'm a Federation Architect here at Sun Microsystems working on the OpenSSO project. And I'm Daniel Raskin. I'm a Senior Product Line Manager also working on OpenSSO in the market. The thing that we were going to talk about today is sort of what you might call some identity stuff in the SaaS world that you guys have been working on. So the big thing we've been noticing is we've been seeing more and more uptake on people asking about how to actually do federation, not only to business process outsourcers or affiliates or subsidiaries, but actually more and more SaaS applications. It's a growing problem that's been occurring within organizations because within the enterprise, organically, people are starting to use Google Calendar, Google Mail, Facebook, and they're using their work identity when doing it. And so more and more as this has been a growing concern, we've had to think about how to federate to those applications, how to actually have single sign-on from the internal applications to those SaaS applications. And so what we've been doing is we've been building flows to focus on helping people federate with Google Apps and Salesforce.com. And what we plan to do is continue down that road with any SaaS application that supports standards-based ways of doing federation, we're going to support it in our app as a way to make it very easy to drive those connections and essentially build federated mashups. So in that sort of, I guess, cross-firewall world of identity management and doing identity, what are some of the technical challenges people face with that, other than the obvious thing of you have a system over there and a system over here? Historically, the main challenge you've seen is that a lot of these integrations have been point-to-point using proprietary protocols. And we saw that in the past with Salesforce, that they had a proprietary mechanism to single sign-on from the enterprise to Salesforce.com. And over time, that gets very expensive because as an enterprise, you've got N unique proprietary mechanisms to deploy.
2:07And what we've seen more recently is SAML 2 being used as a standard for this so that you deploy SAML 2 to federate with Google, for instance. And then when you come to federate with Salesforce.com, your marginal cost is very low because you've already got the software. Uh, and the expertise in-house. Backing up a little bit, I mean, what is the, what is sort of like the identity syncing that people are doing between these? You've got a couple of options with, um, systems like Google and Salesforce. You actually have to have an identity there in their systems. So you've got to have some provisioning of identity. And, uh, perhaps most importantly, deprovisioning when employees leave the company. Right. That's always the, uh, the most important one. You know, IT and HR say, yeah, we want employees productive as soon as they come on board. But if it's a couple of days, that's not too bad. But as soon as an employee walks out the door, you want them out of the system. Right. I guess you also want them very unproductive once they leave the door. Yeah. That's right. That's true. The, uh, the answer to that is to build, um, provisioning adapters into products like identity manager. Right. So that's kind of out of our scope a little bit. Um, and then they just, it just works in exactly the same way as you create an Active Directory account when their user comes into the organisation. You create a Google Apps account. And then they can go there for their Gmail. Uh, and in some other systems, um, you don't even need to do that. In some systems we see, um, all that matters is that you are an employee of, uh, this, this enterprise. And in that case, um, you don't need any state at your service provider. You just need that, um, single sign on transaction. Right. To say, this, this person is a current employee. And that's, that's kind of, uh, a really great one because in that case you don't have to share credentials at all. So, in that case, when you think about security, it's, you know, that application doesn't need to know who that user specifically is. It just needs to have that circle of trust between the identity provider and the service provider.
4:11So, you've named, uh, Salesforce and Google and some other things. And what are some other SaaS services that, that people are integrating with across the firewall? So, we're seeing uptake. We focused on, um, Google and Salesforce because those are the ones that we see the most opportunity. And in fact, in, particularly in Europe with Google Apps, we've had some very large, um, deals where people are, are federating, you know, 20,000 employees, 30,000 employees. Oh, right. To Google Apps. Others that you can see popping up more and more are folks like Doppler or Twitter or Facebook. The problem with, uh, that we face in SaaS, I mean, going back to your original question around the, the business challenge. I don't think it's as much a technical challenge as much, as much as getting the SaaS applications out there that are really popular. And oftentimes the primary, um, service in their respective space. So, for example, you know, you have Facebook and, and MySpace, but beyond that, you know, there's not a tremendous amount of, um, you know, second tier, um, companies that come close to having the reach that those, those organizations have. Sort of a winner take all. Yeah. And so when, when they have that kind of scale, incenting them to actually move to a standards-based way of, of doing business is the biggest challenge. Right. In other words, you hear a lot of uptake into discussion about OAuth, which is still young. You have some popping up doing SAML authentication and others doing, you know, open ID or other ways of, of, um, connecting. And so there, there hasn't been a consistent way for all these different SaaS applications to do federation on and on again. So we, what we'd love to see is, is some kind of convergence where more and more of these services start following in the, the tales of, of Google or Salesforce. And, you know, SAML is a great way to connect. It's something people are doing to connect to that enterprises. Why be different? In, in other words, I don't care if it's a SaaS application, business process outsourcing, or, you know, partner or subsidiary. You know, I want to have a repeatable, scalable way to connect with them and, and for it to be simple and uniform. Um, and so I, I, I think we, we're not at the point where we've seen mass adoption of a consistent way for a lot of these SaaS applications to connect yet.
6:15There's a lot of data initiatives up and running and things like that. It sounds like what you're saying. It's, it's, one, it's a combination of, of the leaders not necessarily having the pressure to have to fix that problem. Yeah. Because of the leaders. But also just because of the newness, like you're saying, their betas and things like that. I mean, do those, are there other factors that are sort of like, why we don't have perfect identity federation or, or, or whatnot now? I think that's a big one. I think getting kind of agreement across the board on what they're going to implement is, is a difficult one. I don't know if you. Well, I think as well, um, as far as a lot of engineers are concerned, there's always a temptation to, um, build your own. Right. And, um, you know, it's, it's a fairly easy problem to understand, you know, you've got to get some, uh, single sign on across internet domains. And, um, you know, just about anybody could come up with something in an afternoon, but coming up with something that's scalable and secure, um, is a bit more of a challenge. And then coming up with something that, uh, can be adopted industry wide, well, you're really into reinventing the wheel there. There seems to be a whole lot of new entrance to it. It seems like identity was very much owned, if you will, by the enterprise identity people. And there wasn't much, I don't even really know how to characterize them because they're not always necessarily consumer people, but they're just new developers coming on and doing identity things. Since, since you guys obviously being at Sun have a lot of enterprise experience, how does this sort of new wave of identity stuff compare to the existing enterprise? Well, open ID has come along in the past few years. Um, an open ID came along, um, with a couple of aspects to it. One was to give users, um, a URL as their identifier. So to give them something to present, um, as their kind of universal ID. Great. And the other was as a reaction against perceived complexity in SAML 2. Because SAML 2 is based on XML, it's got digital signatures, and the perception was it was pretty heavy weight and hard to deal with.
8:17And so you've, you've got these kind of two forces that got behind open ID. Um, and the, the, the nice thing about the users having their own URL, a general problem in identity when you're doing a single sign-on is if you have a service provider that provides service to a whole bunch of, uh, identity providers, so identity providers where you log in, where you have your account. Somehow, um, you've got to figure out which identity provider a user is coming from. Mm. So if you're going to Google Apps to get your email, I've got to know somehow that you're from Redmonk, so I can hand off to Redmonk to actually log you in. I mean, this concept of the user having the URL kind of neatly gets over that. But you get into this whole, um, uh, set of trade-offs that if the user has a URL he gives to everybody, then suddenly his identity can be linked across all of those different service providers. And is that actually a good thing? We've seen that come up. We've seen, um, some adoption out there in Web 2.0 land, um, but it's solving a really different set of problems from the enterprise, because in the enterprise you tend to have a much more static, uh, set of partners. And, you know, the, um, the onus is on, uh, security. You know, the real emphasis is on, is on security. There could be no question that, um, an employee from IBM is accessing, uh, my documents out in, uh. Right. Getting to the, uh, the network we're gonna see, which we'll, we'll get to in a little bit. So, I mean, what we're gonna see is sort of, uh, like we were talking about, having integration between Salesforce and your local network. If someone else wanted to do this, aside from you guys, like, what do they get to do this? The first thing is just to go to opensso.org, um, hit the download button, and you can download OpenSSO. So, it's an open source project, uh, the binaries and source code are freely available. And, um, I posted some email to the mailing list, uh, a little while ago, detailing step-by-step how to federate with Google.
10:24So, uh, you spin up your, um, uh, OpenSSO instance. And you need to go to Google and buy Google apps for your domain. So, you know, a couple of test users at 50 bucks a piece. And then just, uh, follow the instructions. Configure a local SAML identity provider. And then, uh, set up your, um, signing key from there in Google. And then you're pretty much in business. It took, when we did it earlier this year, um, it took about half a day. And that was because I actually had to, you know, do some hammering on OpenSSO to get it to work that first time round. Right. But it's very, very quick now. In a future release, right now, you have to kind of create, um, a service provider for Google and, you know, type in some stuff. In a future release, we'll make it very much more streamlined. So you just have to say, okay, my domain at Google is example.com. And it knows the-- Right. It follows the convention. Yeah, exactly. Google has a convention for the URL that you've got to, that you've got to configure it with. And we can just slot that right in. Well, that sounds great. Well, we'll check out a demo. Okay. Thank you.