Yesterday I had the opportunity to contribute to BrightTALK’s day-long Cloud Security Summit with a webcast called Making Identity Portable in the Cloud.
Some 30 live attendees were very patient with my Internet connection problems, meaning that the slides (large PDF) didn’t advance when they were supposed to and I couldn’t answer questions live. However the good folks at BrightTALK fixed up the recording to match the slides to the audio, and I thought I’d offer thoughts here on the questions raised.
“Framework provider – sounds suspiciously like an old CA (certificate authority) in the PKI world! Why not just call it a PKI legal framework?” Yeah, there’s nothing new under the sun. The circles of trust, federations, and trust frameworks I discussed share a heritage with the way PKIs are managed. But the newer versions have the benefit of lessons learned (compare the Federal Bridge and the Open Identity Solutions for Open Government initiative) and are starting to avail themselves of technologies that fit modern Web-scale tooling better (like the MDX metadata exchange work, and my new favorite toy, hostmeta). PKI is still quite often part of the picture, just not the whole picture.
“How about a biometric binding of the individual to the process and the requirement of separation of roles?” I get nervous about biometric authentication for many purposes because it binds to the bag of protoplasm and not the digital identity (and because some of the mechanisms are actually rather weak). If different roles and identities could be separated out appropriately and then mapped, that helps. But with looser coupling come costs and risks that have to be managed.
“LDAP, AD, bespoke, or a combination?” Interestingly, this topic was hot at the recent Cloud Identity Summit (a F2F event, unlike the BrightTALK one). My belief is that some of today’s tiny companies are going to outsource all their corporate functions to SaaS applications; they will thrive on RESTfulness, NoSQL, and eventual consistency; and some will grow large, never having touched traditional directory technology. I suspect this idea is why Microsoft showed up and started talking about what’s coming after AD and touting OData as the answer. (Though in an OData/GData deathmatch, I’d probably bet on the latter…)
Thanks to all who attended, and keep those cards and letters coming.
re: API end-points and boostraping SAML+OAuth
Eve,
You mentioned boostraping SAML+OAuth trend, and how some cloud providers are utilizing this mechanism for controlling access to APIs. I would like to point out that, while this is true, it is being more as a UI/UX technique rather than a Security measure. What I mean by this is that the SAML+OAuth is not the “exclusive” way to authenticate to APIs. It is “one” of the ways. Since it is not the only way, there are other back-doors possible, which can create security loopholes if not addressed properly.
I think the SAML/OpenID + OAuth bootstraping has to become the exclusive way to authenticate to the API, before it can be considered a security measure.
Would like to hear your thoughts on this…..
Saqib
@weaselese
Hi Saqib– I’m not sure what you mean by “UI/UX technique”. For web services in an enterprise, often OAuth is used in what’s referred to colloquially as a “two-legged” pattern, which doesn’t involve collecting user consent for delegated authorization because there’s no user in the picture. In any case, your point is well taken that the weakest-link security mechanism over an API is effectively the strength of all the other mechanisms too. :-)
Hi Eve,
Correct. Enterprises usually use 2LO, whereas 3LO requires user consent. However, most web service providers offer both – 2LO for Administrators to authorize access to data, 3LO for the individuals.
The point I was trying to make in my earlier comment was that the 3LO is usually offered with SAML (SSO) because it provides the user with a familiar UI/UX (SAML SSO page) to login. Users are usually familiar with the SSO login page, as they use it for other apps as well. This way there is no learning curve involved, and that is why I call it UI/UX technique. But since most services offer an alternate way to retrieve the 3LO Token i.e. without going through the SAML logon, I don’t see SAML as a security control.
Saqib
Ah, okay, I see now what you’re saying. Indeed the most likely scenario for getting the SAML token in the first place is through a user login, though the SAML-OAuth profile I mentioned is “agnostic” about where the token came from.
I’d say that the nontechnical aspects of the token exchange far outweigh the technical aspects of whether user delegation is involved or not, since a whole bunch of trust establishment has to go on in order for any SAML token to be reliably turned into an OAuth token. Today, it’s not like you can walk up to any OAuth-protected service and just wave an arbitrary SAML token at it; it has to be expecting you. If the OAuth authorization server requires a SAML token with LOA4 or something, the input token will have to have certain aspects before it passes muster.
BTW, the UMA group is one community, among others, that has an interest in decoupling the OAuth resource server and authorization server, such that it’s possible to have them meet dynamically in the context of a user and to have the former figure out how to accept tokens coming from the latter. So in a way we’re trying to “technify” this piece of OAuth trust establishment — but there will always be aspects that are out of band from the protocol. I hope to write more about this work in a future post.
okay now i am lost (not the first time). but will wait for ur future posts :)