EIC 2012 Session: Federation or Synchronization – the Future of the Cloud

This panel is Federation or synchronization the future of the cloud. Okay. Now I already told you my thoughts on this. So I'm a little prejudiced, but these guys might have a different opinion. Are you ready to take over? Hopefully, yes. I'm. I'm very sorry, but it's all you, I had to take care. Yes. So thanks for the, for the introductory presentation. We had Dave, the technology has been around for such a long time. Yet.

We only see good use of it in certain technologies and in certain geographic areas around the globe, what do you think keeps most of the organizations back from really moving into that next step and adopting that technology it's been proven to work and, and there's been very, very good progress being made in actually deploying it. So, so what's keeping people back from using it.

I, I think some of the things that are keeping people back is that it requires 'em to open up and that makes them vulnerable to an extent. And a lot of organizations have a reputation. They have a brand they want to protect and opening up and exposing that information is scary to them. So that's part of it is just risk averse nature of some organizations, a lot of the smaller companies who are using things like Facebook connect that are lightweight, they, they don't have a lot to lose. So of course they'll take those risks and open up and create those federations.

Whereas some others might not Okay. But I, I do understand that there's even more lightweight ways to, to, to get connected, but the, the older model, like synchronization, like really hooking two systems up and integrating them deeply tightly together, which is still stuff that's, that's being preferred by many organizations that, that gives me even more shivers there. There's so much more to that.

So, so I would've expected that organization say, okay, we shy away from the hassle of doing that deep integration. And we are instead switching to Federation as a, an intermediary step because I don't open up that much. I don't give up so much information in, in Federation cases.

And, and then maybe later when they merger or acquisition happened, we, we really open up and integrate. Why do you think that this is not the intermediary? I think we're All gonna be in agreement. Federation has a very, very strong future. And the underlying word is future.

If, if everything was federated today, if every service I chose to use both inside and outside of my organization supported SAML tour, there are no technical barriers that are gonna prevent us again there. So I think we are in a agreement with, with, with Dave's statement that prefer you would prefer to federate, but that is not the reality of the runtime world for the end to end experience of the business user today. So invariably we live in a mixed world of synchronization and Federation.

How long that continues will really be driven by how quickly the service, the services and service providers roll out Sam, Sam support, or, or any form of Federation, but then is not the talk of the day that this will all be open ID, open ID connect is gonna be the way to go. I mean, as technologists, we don't make this easy for business people to make the decision as to where to place their bed.

So One of the other reasons besides the lightweightness or heaviness of the protocols is the cost of making direct connections with every one of these partners that, that Dave showed in, in his setup piece, that that can be expensive and prohibitive in some cases. So what a lot of people are doing to address those cost issues is creating Federation hubs, where they'll create a, a connection into the hub and then use that to get to many different endpoints. So that reduces the cost of making those direct connections.

And I think that that sort of thing, and when the hubs start to connect to the hubs Federation will really take off without the cost. You know, we've seen the adoption of those hubs in, in specific industries yet, and very, very successful where marketplaces are using those hub and spoke mechanisms to actually facilitate the integration using Sam and, and Federation technologies. Yet it's still limited to those verticals and it, it didn't well blow out to the whole market.

Not, not every industry is, is certainly ready to do that. And what I found during our consultancy work is that many organizations still shy away from doing that limited opening up due to regulatory problems and the unpled legal situation. So I'd be interested to, to hear your input on what, what your experiences are with, with prospects that are interested technology wise, but then say, oh, well, our legal department said they don't know how to deal with that.

Well, I mean, maybe we should take a, a step back. I mean, even, even if there are, even if there is a desire on both sides on the client and the providers front to fully support a hundred percent federated model that should take away the need for synchronization, synchronization still needs to happen. Salesforce leading the industry, great support for SAML still is there, they're still an account that is required. We are in the business of providing open, open protocols and open technology that enables that synchronization to happen because the provider itself still requires it.

They have an account, the personalization and the authorization model requires that there is a, some form of transport goes on for that. So it's, it's not really just an issue that the business isn't allowed to do. It it's that synchronize, you know, to make the choice between synchronization or Federation, they sort of are still locked hand in hand in so many of the provider environments today. So I know I haven't answered your, your politics question, but, But so the, the thing about that, that I would discuss with the prospect is that Federation can be an ambiguous or confusing word.

It's not one that we use every day in our normal way of talking. Dave set a piece kind of helped us see, like we've been doing federations and what that is, makes it a little less abstract, but still when it gets to a procurement manager or something like that, it could be a turnoff or a legal department. And so then what we'll do is ask, you know, do you outsource, do, do outsource development? Do you outsource your payroll? Do you do outsource anything?

Well, in a sense, you're already doing the same sort of things. As we're talking about with Federation, you're sharing your data, you're sharing your information. What sort of contracts do you have in that case? What sort of, what sort of legal ramifications are there? If the outsource provider doesn't fulfill its obligations and Federation, those, this kind of uncommon word is the same sort of thing. So look at your contracts and can those be reused? And oftentimes the case is yes, they can. Yeah.

And maybe to come back to that, we find as an identity, an access governance and, and a provisioning provider that we're very frequently asked to maintain that physical manual provisioning, synchronization control point for the business. There's a lot of apprehension about using value-based services in the cloud.

And I think the business feels that if they can extend the level of control they have within the data center around joiner mover, lever processes, and they can sort of see that in the technology that they have successfully deployed around provisioning, they're more inclined to, they have control. They're more inclined to take on the service. So they'll tie to an HR event, a what is fundamentally a synchronization activity, hopefully over ski to, to physically create, manage that account. And then on the move or join, move, or leave event, they'll actually take it away.

So that's sort of, depending on, in some ways, synchronization and provisioning to give them the level of control that they feel they need in order to then have the runtime session run over Federation. So it's a kind of a strange mix.

So what, what the feedback that, that I got was that sometimes business was, was really pushing for it was really looking into it. And then the, the it identity administration guy said, I, yeah, well, we, we don't want to extend the stack of technology that we have in place was, was, was yet another tool aren't there other ways to, to do it?

How, how could one get around it? How, how could one make, make the, it guys see that they would actually benefit from, from using Federation instead of doing it the old fashioned way and setting up this big, huge fad pipe with synchronization.

Yeah, definitely. When you have to go out as an administrator and create an account in dozens and dozens of cloud services, or create shadow accounts within your directory for your partners, and remember that, you know, to email those partners, to remind them, Hey, have people left, have people been added? I need to delete them from my active directory because my auditor's coming. That becomes a very easy case to make, to say, well, if you federated, you wouldn't have to create those accounts in the cloud service.

You wouldn't have to go to the partner and say, you know, is, is this guy still in this role? Does he still work for you? This sort of thing instead, it would just be coming into the organization or he'd be projecting it out and making that it operation run more smoothly.

See, I guess I would also challenge to some degree. I don't think the end user population wants Federation. I don't think they even know what it is.

I mean, if it facilitates single sign on that's something people. And I, I think when we talk to, to customers and end users, quite often, they don't even still know what single sign on is. They just know that they don't want to have to remember a password. They understand that user experience. So we are kind of obsessed with it as technologists so that it, it it's very much a facilitating technology for us. So how we're gonna sell it is back down to reduced cost reduced administration.

And to some degree, a high level of, of real security, if we, we are tying the business events within the business environment to the access that people need. So, so it's actually, again, back to the business user, addressing the business user and saying, you know what, I, I, I, as it know that you would like to cooperate with this and that partner, and while you, we could do that integration, it's gonna take time. It's going to be costly. Yeah. But we could also federate and you know what, there won't be any sign on issues for you. You'll just log in and use it.

Is, is that the way to promote Federation Today's, it's the primary use case, right. Really single sign on the user experience is the primary is the primary selling use case, right?

I mean, some part of it is onboarding faster access. If you are, you know, just in time provisioned into the service, or you are, isn't requiring that prestep, but largely it's the user experience.

And, and there are certainly others drivers like regulatory compliance and easier audit and pushing that audit onto your partner rather than you having to own all those accounts. So it reduces the, the OPEX associated with, with connecting to all those partners. Okay.

So I, I recently had a, a little conversation about single sign on in the enterprise and especially using enterprise single sign on technology to reach out to the cloud, to reach out to applications of the partners and those vendors today, claim that they can do single sign on to all those applications. And they actually claim that the benefit is that you, as the internal, it remain in control of who uses a certain service, because you enable them to single sign onto it or not. And by that they execute access governance to that.

So, whereas the benefit in that compared to Federation, then I think a great phrase that comes to mind in that is control with convenience. We want to enable convenience for this is really the selling point for the, for the whole technology stack, right? Is that if we can enable convenience for the end user, but we can maintain control. And I think one of the reasons we see a fair amount of synchronization in band with it is, is that that is what is needed to maintain that control.

Sometimes it's enforced by the SAS provider themselves, but so frequently true access control within the application is derived from attributes that are managed through synchronization. So I think it's, it's a Bit of both.

So, so we are not going to get rid of synchronization in the short run, but we're working on it. Right.

I, I don't think that we'll get rid of synchronization even in the long run. I think you are gonna need both. I think that it, if, if you rate wait until you federate, before you create that account, then everybody has to log in before you can even find them. Right. So in certain use cases like an address book searching for somebody they're a brand new employee, how am I supposed to give them, you know, the access to a particular lab or something like that when I can't even search for them and find them yet, cuz they haven't logged in. So you're gonna need both for certain use cases.

And I don't see that changing even in the medium or long Term. And if we, if we take the word of synchronization to be a, a subset or sweep, decide you look at it of, of the account act of provisioning to that point, it's always gonna be there because even if you're able to create accounts just in time, how do they get taken away? How do you deprovision we haven't really addressed that in band. So we're still gonna be, if you think of synchronization as a, as a deprovisioning action, that still it's very much required even in the most advanced models today.

And, and I think what you're gonna see is a tighter integration or marrying of synchronization in Federation. So they're working more seamlessly, More hand in hand.

Yes, Exactly. So like, absolutely. Yeah. You could imagine cases where you start synchronizing accounts and seeing accounts in some other service. And one of the attributes that you're sending over is an access token that you can then use to make calls back, to get additional stuff, or you might see that account with some entitlements. So once they finally do single sign on over into that other domain, those entitlements are enforced and, and I see that those two working more and more together. Yeah.

And, and less apart like they are. Okay. And I guess we should throw in a plug for, we're trying to do some of those things in the, in the alignment of skim as a fundamentally account and provisioning standard with Sam and being able to profile and map attributes between the Two, an Open ID connect, an open ID connect.

So, you know, there's a lot of work going on to try and keep these things together. Okay. Thanks.

So we, we definitely see that Federation is not, the cure is not the patch, but it's going to augment what we already have. And if the technologies are promoted to better work together, we will definitely share our benefits here in the future. But it's definitely, so that synchronization is not going away. It's just complimentary to Federation. So thanks to you guys for being up in stage next. Oh welcome. We have a short presentation. Thank you. That will de dive a little, little bit deeper. Yes. Give us a hand.