Yesterday’s hack of the AP’s Twitter account was big. Not only did the impact it had on the stock market prove Ranjeet’s thesis that Twitter is now a SOX (Sarbanes-Oxley) application, it added to the long list of Twitter hacks that have led to repeated calls for Twitter to add two factor authentication (2FA) for their accounts. And the news that came out in the immediate aftermath of the AP hack is that Twitter is working on adding 2FA.

But this creates an interesting issue. Pretty much everyone that added 2FA after the now legen…wait for it…dary Mat Honan hack implemented the same mechanism: add a mobile number to the account, and supplement the normal password based authentication with a verification code that is sent to that mobile device via SMS. Works pretty well for your Google mail, your Facebook account, your iCloud account. But Twitter has an interesting challenge here (which may be why they didn’t rush to add it).

This method works pretty well when we’re talking about a personal Twitter account. But the accounts that are most likely to be attacked, and therefore in most need of stronger authentication, are the channel accounts – for brands, celebrities and organizations (like the AP). These accounts are usually not operated by an individual, but rather by teams of people. Twitter has no feature to support this, though there are any number of Twitter tools out there that facilitate this by adding a management layer on top. However, whether you’re using a tool or just managing this ad-hoc, it all relies on the sharing of login credentials – the Twitter username and password. So what happens when 2FA is added to such accounts? Whose mobile number will be provided to Twitter? As Eve Maler pointed out in an excellent blog post, 2FA effectively kills any password sharing based approach.

It’s a far more interesting question to consider when you expand the arena to include enterprise applications. The IAM suite of products includes Privileged Account Management or PAM (aka PUM) products that are specifically designed to tackle the problem of shared accounts, usually highly sensitive (and therefore needing stronger protection) admin accounts. PAM products usually work by taking over the use and management of the shared password, either signing the user in transparently (without revealing the password) or revealing a one-time use password after the user has authenticated themselves using their own unique credentials. There’s a very direct impact on these tools if the application they are managing authentication to suddenly changes their authentication model. And with more and more enterprise applications now in the cloud, and adopting this kind of 2FA, one wonders what the future of PAM will look like (welcome to my world).

Maybe this is why Twitter didn’t rush to add 2FA to their accounts, because they realized that doing so would break the usage model of some of their most valued users – channel managers. And if they now roll out fast and cheap 2FA (as Eve put it) in response, then it’s likely that the accounts they are doing this for are unlikely to turn it on because of the impact it has on their operational model for using/managing Twitter.

The only real short-term answer for Twitter (and similar applications) is to roll out true delegation of usage rights to multiple identities. The model by which Facebook Pages are managed, where people authenticate using their individual Facebook identities and are granted fine-grained (!) admin rights, comes to mind here. This then ties back to Twitter being a SOX app and the need for IAM systems to treat these applications like any other enterprise application.

The only real long-term answer for all applications is to do real (not fast and cheap) MFA (multi-factor authentication) and eliminating shared accounts by combining a delegated authorization model with claims-based recognition of identities. That, unfortunately, is a much harder problem to solve.

[UPDATE 5/23/2012] – So Twitter has finally added two factor authentication. And it is, as expected, not done the way that they needed to do it (and why are they calling it “login verification”?). Let’s see how channel managers respond, and if Twitter notices (when they track who turned it on).

But what is far more interesting to consider are the ramifications this hack and Twitters response measures have had (or not had, depending on who you talk to) on the ecosystem that integrates with Twitter via it’s OAuth implementation. This article brought up the fact that 3rd party apps authorized to interact with Twitter are still able to tweet despite the passwords being reset. In other words, the resetting of the password had no impact on whether they still had access to the account. Why is this important? Because if you consider one of the possible motives behind the hack, the attacker could have used the time that they had control of the account to add an additional application (a Twitter client like Hootsuite, for example) to the list of authorized applications by going through the flow and issuing an OAuth token. Now, even after the password has been reset by Twitter and control of the account restored to its rightful owner, the attacker still has access to the Twitter account through that app. They are therefore able to send out tweets as that account, which would probably get noticed and caught pretty quickly (though an unsophisticated user may not know how to tackle it, and might just re-reset their password and think that it will fix the issue). Or worse, the attacker could simply spy undetected on the direct messages for that account, for a very long time. In this brand driven world of celebrities, politicians and corporations increasingly built on Twitter, think of the significant damage that could be done.

And you can extrapolate from this issues that could arise in the case of mobile apps in the enterprise. What impact does cutting off SSO access or changing an account password have on the access that an app a user installed on their mobile device has? BYOD has made this a very real challenge for your IAM program.

So, what should have been done here?

Should the password reset have automatically revoked the OAuth token for every single authorized app? If you’re like Paul here, that may be a huge inconvenience.

Paul may be an extreme example (unkinder words have been uttered for him). But in a world where we all have multiple services and multiple devices that we use to access Twitter, the number can get up there pretty quickly. I checked my number, and it turned out to be 13, but that’s with me being pretty ruthless about going in and removing stuff I haven’t used in a while. This led to a nice little discussion on Twitter (which I captured), but no consensus on a solution.

My perspective is that since it is usually hard to pinpoint the exact time at which an account got compromised, all tokens should be immediately revoked. This is especially relevant in scenarios where a targeted individual (as opposed to a whole group of users) gets hacked. And yes, it may be painful to have to go through and reauthorize all your apps, but it will at least get you to clean up those apps (and maybe come d0wn to a more reasonable number, Paul). I’ve written in the past that reviewing which 3rd party apps have access to your cloud services on a periodic basis is a crucial step to maintaining your security posture. And as you can see from the feedback message Paul got when he changed his password, Twitter did ask him to do just that.

As for what other measures are needed to handle this in the enterprise? That’s the topic for a whole other blog post.

(Infographic from Geraldes’s Blog)

Tags: Hack Attack, OAuth, Passwords Must Die, Token Management, Twitter

Nowhere was this captured more vividly than in our FedEx Day projects (for more on FedEx day, read this). The passion different teams brought to the table was amazing to behold, whether they were creating an ebook or a video about our core values, connecting our product, support portal and our internal issue tracking system together, or simply putting together a how-to guide on surviving an afternoon with Victor. You could really sense the talent, commitment and drive in the room.

And they’re a great group to hang out with too.

It’s been a great month. We officially launched SCUID Lifecycle earlier this month. We’ve accompanied that with a blitz of analyst and press briefings, and the coverage has been quite encouraging. Some have recognized the innovative approach we’re taking, while others have commented on how much of a game changer it can be in identity management. All of this means that 2013 is going to be a real roller coaster of a year. Expectations are high, none more so than what we expect of ourselves. And it’s going to be fun delivering on the promise of the SCUID Platform.

And if you want to join in the fun, check out our careers page. We have a number of openings, especially in the product team. But we’d love to hear from you even if you don’t see an immediate fit in the jobs posted, because we believe first and foremost in talent and the value of forging a partnership. If you want to work in an environment that is focused on GSD, where creativity, free-thinking and collaboration is encouraged in a judgment free zone, then drop us an email or reach out to any of the team on LinkedIn. You’ll be working with cutting-edge technology to build real solutions that form one of the foundational elements of our customers’ infrastructure. And you’ll be surrounded by some very talented people. And me.

Tags: Careers, Fedex Day, Identropy, SCUID, SCUID Lifecycle

Eric always does an outstanding job curating content and speakers for his conferences. It was no different this time, but what was different was that Eric felt it was time for Identity to make its way back into the Defrag conversation. He explained why in this blog post. Consequently you had Kim Cameron talking about the emergent need for Identity Management as a Service. And in arguably one of the best talks at Defrag, Ian Glazer waxed poetic about ‘Killing Identity Management to Save It‘. His assertion that the lowly comma is probably still the single greatest identity invention to date not only got the crowd laughing (and gave me the premise for one of the better slides in my deck), but also perfectly captured just how stuck in a rut identity management is today. He made the case for a revolution in identity management by revisiting the models and architectures of the past (and present), and talked about the need for identity to become a part of the fabric of enterprise applications, instead of being a separate entity that lives in a static, disjointed world.

All of which fed neatly into the talk I gave on ‘The IDaaS Powered World, or: How I Learned to Stop Worrying and Love IAM (Again)‘. I wanted to lay out the vision of a future built on identity services, and what it could mean for interactions in the online world when we truly embrace externalized identity (aka Bring Your Own Identity), a platform approach to identity usage, and cloud-based identity management. You can check out the slidecast (slides + audio) below.

The talk was really well received, giving rise to some good discussions both online and at the conference, and I’ve captured some of the reactions here. And I’d like to think it gelled nicely with some of the other, non-identity themed talks at Defrag that focused on the new ways of building applications and experiences online. The vision expressed in my talk is a driving influence in how we are approaching building the SCUID Platform at Identropy, so it will be great to get your feedback in the comments. So chime in with your thoughts.

Tags: Bring Your Own Identity, BYOI, Cloud Identity Model, Defrag, Defrag2012, IDaaS, Identity as a Service, Identity Services

Well, now comes this little gem from the land down under, courtesy of Simon Harvey (with Mark Perry specifically bringing it to my attention on twitter). The lobby group for Australian telcos (most notably Telstra, Optus and Vodafone) has declared that SMS technology should no longer be considered a safe means of verifying the identity of an individual during a banking transaction. In other words, don’t use SMS delivered OTPs.

Why are they taking this remarkable position of declaring their own service ‘unsafe’? It has nothing to do with interception and decryption of communications (as has been worried about by many). In what seems incredibly reminiscent of the issues outlined in the Mat Honan attack, it is a process issue, and one that the telcos are apparently saying they don’t want to fix (in the name of consumer convenience).

The problem lies in the ease with which a hacker can implement a phone porting scam, in which they move someone’s mobile phone number from one service provider to their own, thereby receiving the SMS delivered OTP on their own device. At the heart of this is another identity verification problem. Porting the number over in Australia simply requires providing the mobile number itself, and either the persons date of birth or mobile account number – incredibly easy to obtain pieces of information by any measure. The telcos had considered adding the equally insecure Static KBA mechanism in which subscribers added security questions to their accounts, but then backed off from that.

The fact that a subscriber can have their mobile number stolen so easily is in itself a major concern, and one that the telcos aren’t taking on because of “reasons of competition and database performance”. The article quotes Communications Alliance chief executive John Stanton as saying

“Apart from making the porting process more time-consuming and less convenient for hundreds of thousands of Australians every year, additional ‘security’ may be seen as a tool to lock in customers, hinder number portability and thus be deemed to be anti-competitive,”

Except that the Mat Honan hack showed us just what can happen when you put convenience over security.

So What To Do?

First off, the telcos really need to make the process of porting numbers less susceptible to fraud by incorporating better identity verification than simply asking for a date of birth. Identity verification services like those from Lexis Nexis provide a far more robust way to spot verify the caller on the other side of the line, or at the store. Our mobile numbers have become far too important in the context of our lives to be so poorly protected.

As the article points out, backing out of SMS delivered OTP is going to be hard for a number of the services that have incorporated it. While the telcos are specifically advising against the usage in banking transactions, it is hard to imagine enterprises or identity providers not considering their risk to be in the same ballpark. But what options do they have?

The article points out how moving to physical tokens is not a practical solution for most (and it’s not even a good option). Soft tokens via mobile apps is a decent alternative (provided there is good authentication and security built into the app itself), but is not as inclusive in a world where not everyone can afford expensive smartphones. The same goes for mobile apps that leverage the smartphone camera and mic for simple biometric authentication. The use of identity verification services as described above is a little too intrusive or onerous when used to secure common transactions, but should definitely be considered for high value transactions. And there will still be enough services that consider the threat to SMS-delivered OTP to simply not be great enough to rule it out for certain levels of transactions. All these options and more (Any that I missed? Let me know in the comments) should be considered and blended into a truly risk-based security model.

Ultimately though, this problem will only be tackled in the move from authentication to recognition, where multiple, non-intrusive techniques will be layered together to provide services a high level of assurance regarding the interacting identity. In the meantime, these telcos really need to fix their processes.

Tags: Identity Verification, Knowledge-Based Authentication, Multi-Factor Authentication, One Time Password, Phone Porting Scam

However, there was a bright shining moment of the kind of identity management madness that we’ve all come to expect from Catalyst. And it came during an identity focused set of talks by Lori Rowland and Ian Glazer. Lori’s talk tried to cover all the various challenges for IAM as it pertains to cloud computing, while Ian took on the thorny topic of externalized authorization with his usual wit and wackiness. The talks were great, but what elevated the sessions even more was the back channel discussion happening on Twitter in parallel, where we not only discussed the points being made on stage, but at many times just completely went off the rails. It doesn’t do it justice (you seriously had to be in the room and on Twitter to appreciate it), but I tried to capture some of the twitsanity below. Enjoy.

Tags: Authorization, Cloud Computing, Cloud Identity, Externalized Authorization, Gartner Catalyst Conference, GartnerCat

It’s a powerful article at an emotional level too, and I hope the mental images of Mat losing all those digital memories – photos, videos – of the first year of his child’s life gets people to pay attention. But I want to take this opportunity to discuss both the simpler, individual level implications of this as well as the larger identity ecosystem level implications of this.

Please read the article to understand the details and nuances, but for the purpose of discussion I tried to visualize the attack plan that let the hackers take over and erase Mat Hogan’s digital world.

Anatomy of the Hack

Remember, all they started with was his Twitter handle.

What Does This Attack Reveal?

The factors we rely on to verify identity are (simply put) useless

Apple spokesperson Natalie Kerris told Wired: “Apple takes customer privacy seriously and requires multiple forms of verification before resetting an Apple ID password“. Those multiple forms equates to knowing both the billing address (easily figured out) and the last four digits of a credit card number on file. Information known to anyone you order takeout from. Or any number of daily deal websites, for instance.

Security questions suck (and everyone knows it)

The forgot password procedure does involve correctly answering the security questions set on your account. But we know that the majority of the time, people simply do not remember what answers they set a long time ago, and in an attempt to be helpful to the customer, the “understanding” customer service folks will ignore this failure on the part of the user. Can’t blame them. After all, they have a backup process just for this eventuality (and it is an eventuality). And keep in mind that if the answers are  memorable enough for the user to remember no matter how long ago you set them, they are also very likely simple enough for a hacker to figure them out by looking at our digital footprint.

The simplest attack vectors come from bad processes

Taking control of an Amazon account via forgot password requires providing a name, billing address and credit card number as authentication factors. But what allowed the hack to be pulled off was that the hackers could manipulate those factors – by adding a (fake) credit card number to the account – without having to authenticate, because all you need is the email address and the billing address. Amazon has quietly changed this policy now, but this should force everyone to review their policies around data management and customer service. How many times have we had to give our password over the phone to a customer service rep on the other side of the line? [Update: Apple has also suspended their customer reps ability to do password resets over the phone. But then what is someone who doesn't remember the answer to their security questions supposed to do?]

We need to follow and analyze the trail

If the sequence of separate identity events that allowed the hackers to take control of Matt’s Amazon account had been connected by an audit trail that was being analyzed, then maybe it could have been caught. This is harder done than said, but that’s why identity activity monitoring and identity change monitoring has to be a part of the underlying fabric to detect when manipulating events are underway.

The weakest link

The forgot password feature which relies on simply emailing a reset link to the registered email address is at the heart of these and other exploits. Because it assumes that access to the email address is completely secure. Which it is not.

The key point, if you didn’t already know this, is that a lot of our online security revolves around our email addresses. Not us (aka our identity). And  with the wealth of data sources out there now, email security in its current form is increasingly easy to hack.

First, the Simple Stuff

Here’s the basic stuff everyone needs to do.

• Make sure you’re backing up your data, and not just on your laptop or desktop. Backup your devices as well. You can even do that over the air now without having to plug them into a computer.
• Turn on two-factor authentication for GMail and Yahoo mail. One can only hope that Hotmail and other email-based identity providers follow suit.
• Review those little used email addresses that you’ve registered as the backup email accounts for your systems. Chances are, you have a pretty poor password on those. Fix that.

Here’s the Difficult Stuff

First off, identity verification needs to grow up. Yes, Passwords Must Die. But so should Static Knowledge Based Authentication (KBA). Information like billing addresses, school attended, mother’s maiden name are so easy to find in this day and age of rich data sources (social, data aggregators, what have you) that to use them is just inviting the hackers in. Companies like Experian, IDology, Trulioo are using new and innovative ways to address the identity verification needs of your systems. And while this needs to be used in a risk aware context, I suspect that the risk in cases like iCloud is not being properly weighed against the needs of frictionless (not necessarily good) customer service and purchasing ability.

In fact, we need to start moving from identity authentication to identity recognition, with identity verification a key component of that move.

Nonetheless, every business dealing with identity management of customers in any way needs to review their model, and if they can’t externalize identity by allowing customers to Bring Your Own Identity, then they need to review their processes and put much better controls in place than those demonstrated by Apple and Amazon in this case.

You might think that this story also highlights the risks of relying on other systems for identity. And certainly a whole lot of CISOs will be fretting over this point and questioning both identity externalization and cloud. Certainly seems to be a poster child for the Woz’s concerns. But this would be misguided. The breakdowns here occurred because identity was not externalized, and was instead being managed internally using poorly constructed and highly flawed processes that relied on 3rd parties in the wrong way. This was not a zero-trust environment by any definition. And as such, it broke in quite predictable places because there were no mitigating controls.

Furthermore, email providers have to understand that they are now the de facto identity providers on the web, and start acting as such. More than any other service (even Facebook, sorry Mark Z), they hold the keys to the kingdom – in the same way that SSO and Privileged Accounts hold the keys to the kingdom in IT. The level of security needs to be commensurate with this increased importance or risk within the broader identity ecosystem. Two-factor authentication using SMS is a first good step, but the move to identity recognition is crucial for email providers. And the ability to layer in risk-based identity within any identity reliant system becomes even more crucial to mitigate against the domino effect exhibited in the Matt Honan fiasco. That chain could have easily been broken at many different points, preventing his personal disaster from blowing up to that scale.

In a weird (but entirely predictable) way, this also validates the point that Jonathan Sander was making in his blog post ‘Is the ID ecosystem #NSTIC wants too much risk for an IdP?‘. The identity providers are already carrying a huge amount of responsibility in the internet ecosystem, they’re just not being treated (or held accountable) as such. Once we start doing that (and it will happen because of stories like these), they will be at the level where supporting the NSTIC requirements will not add that much more to their risk coefficient. On the flip side, the NSTIC process can be used to accelerate the adoption of smarter, better identity management techniques at identity providers like email providers by laying down clear expectations and guidelines. Hopefully this (and more) will be discussed at the NSTIC steering group meeting in Chicago next week.

I don’t think this will be the last time we hear a story like this. But I do hope that the innovations coming out of the identity community will change the game soon.

Update [8/9/2012]: I have been incredibly gratified at the kind words my tweeps have used in responding to this post and spreading it around. I’ve collected some of them here as a Storify piece – partly because I want to come back to this when I need some encouragement, but mostly because I can use it to make Paul Madsen jealous.

Update [8/9/2012]: I have seen some people use the “daisy chaining” that facilitated the attack as a proof point that federation is bad, and even suggested that this somehow proves that Bring-Your-Own-Identity is a bad thing. Far from it. I’ll address the BYOI argument in a follow up post since it deserves a more detailed response. But on the “daisy chaining” thing, you have to understand that this was NOT a daisy chaining of identities. There was NO federation here. The connection between the 4 different identities and identity infrastructures was one of PII data (data Amazon considered not sensitive, but was used by Apple to verify identity) and communication channels (email messages being sent by the forgot password feature to a hacked account). And I also want to make sure that folks understand that I am not trying to sell two-factor authentication (2FA) as a silver bullet here. 2FA is not without it’s flaws, as demonstrated in the story “New Frontiers in Online Fraud” on page 33 of SC Magazine AU (thanks Simon Harvey for the link). But it does make the accounts less of a soft target. And that’s a big leap forward from status quo for most people.

Tags: Amazon Security, Apple Security, GMail Security, Identity Assurance, Identity Providers, Identity Verification, Mat Honan, NSTIC, Password Management, Password Recovery Techniques, Passwords Must Die

Re. @Kim_Cameron (http://bit.ly/NroKfa ) & @MartinKuppinger (http://bit.ly/O3Iwex ) posts, posit that Graph API:IdPs :: SCIM:Apps. Too simple?

I was essentially contending that Directory Graph API would primarily service the Identity Provider scenarios where a SaaS application could rely on an externalized identity store for identity claims, while SCIM would be the API that SaaS applications would support so they could be “managed” by a provisioning infrastructure. My question would prove prescient.

Before I left for the Cloud Identity Summit, I had tweeted that one of my goals at CIS would be to dive into this topic. And John Shewchuk was kind enough to seek me out (thanks John Fontana) and grant me some insight into the vision for how they expect Azure AD (he does not like the acronym WAAD!) to address that aspect of identity management in the cloud. It was a very good discussion, and I hope I do it justice here (but I’ll rely on John, Kim and others to keep me honest).

User Provisioning in the Cloud

Two years ago, at Catalyst 2010, I gave a talk entitled Beyond SPML: Access Provisioning in a Services World (wow, we do like to declare standards dead a lot, don’t we?). You can check out the slides from my talk here, if only to enjoy the manner in which I eviscerated the Black Knight of Identity, Ian Glazer, while simultaneously earning myself the title of Iron Man of Identity. More relevant to this discussion though was my exploration of how provisioning, in particular Just-In-Time Provisioning, would need to evolve in order to service the growth of SaaS apps in a highly decoupled environment. JIT Provisioning was the cornerstone for my view of the next generation of provisioning, living as it would on the backbone of federation interactions like SAML or OpenID flows. It involved SaaS applications using the basic claims received as part of the initial identity interaction to connect with the “Provisioning based IdP” (as I called it on slide 28) and retrieve the attributes and claims needed to create the identity in their own identity store. Further, in order for the SaaS application to then know about changes to the identity and stay in sync with it, a notification mechanism would be needed (see slide 31). This voids the need for a synchronization mechanism (directory synchronization or user provisioning) as the only way to keep SaaS applications updated, and instead makes it more of a pub-sub model that empowers the SaaS application to get notified about changes, and pull them in if and when they need to do so.

And this is essentially how Directory Graph API and Azure AD tackle the prospect of user provisioning. Directory Graph API is inspired by another identity platform API: the hugely successful Facebook Graph API. That API includes a mechanism for change notifications called Real-time Updates. Any application using Facebook can subscribe to changes in data in Facebook, allowing the application to “cache” data and receive updates. Whenever a subscribed change occurs (say to a user, or a users list of friends), Facebook makes an HTTP POST request to a callback URL the application specifies with a list of changes. This is the mechanism that Azure AD plans to adopt (this capability is not available yet, and was the missing link for me) that allows it to actually enable the JIT Provisioning model I described above. In effect, the Directory Graph API with Notifications allows Azure AD to become the Provisioning based IdP I refer to on slide 28. That’s pretty cool.

Rubber, Ready to Meet Road?

And that is how Directory Graph API becomes both competitive and complementary to SCIM. They address two completely different provisioning models – SCIM is clearly aimed at the more traditional push-based provisioning architecture that we are familiar with (you can see where it fits into the model described in slide 4), while Directory Graph API is positioning itself for the newer pull-based provisioning architecture.

And therein lies the real challenge. Because as I pointed out in my previous post on Azure AD, getting application architectures to change is really, really hard. SCIM can be layered on top of existing application architectures easily, providing a quick solution despite the shortcomings of the model. Directory Graph API requires applications to change how they consume identity, which is a much harder proposition – especially in today’s world where polyglot architectures and liberal use of 3rd party tools and open source impose constraints on what you can do. Facebook succeeded in getting many applications to adopt this model, but those were being built from scratch and (usually) had simpler use cases and concerns.

And from an enterprise perspective, the control mechanisms are still unclear in the new model. It’s very easy to understand how one centralizes policies and controls into the provisioning engine in the push model to control what data is being sent when, to which applications and for which identities. In the pull model, figuring out when to allow or deny the pull of identity data and subscription to changes requires a rethinking of both the authorization model as well as the control framework (approval workflows, de-provisioning, etc) governing the identity data flows. And like I’ve said all along, governance models like access certification and “who has what” reporting can prove to be a lot more complicated in a highly decoupled architecture like pull-based provisioning. And while I wouldn’t dream of pushing more enterprise use cases onto a simple protocol, these are core problems to be solved. If Facebook were to be more diligent about privacy or concerned with data protection, this might become an issue for them as well.

To bring this back to where we started, the missing pieces show that Azure AD is clearly about more than “Directory in the Cloud” or “AD in the Cloud”. And it isn’t a provisioning engine either, at least in terms of how we traditionally think of them. It is trying to position itself at the heart of an IDaaS platform, where externalized identity is supported through a pull-based infrastructure. This is a path others are following as well, but what Microsoft (crucially) has is the ability to influence how application architectures evolve to make this a practical reality. That is the key.

Oh, and answering those pesky governance control questions.

Tags: CIS2012, Cloud Identity Model, Cloud Identity Summit, Directory Graph API, IDaaS, JIT Provisioning, Just-In-Time Provisioning, SCIM, WAAD, Windows Azure Active Directory

I tried to make my contribution with a little talk entitled Ask not what Identity can do for the Cloud, Ask what the Cloud can do for Identity. It was part of the track on Cloud Identity Edge Cases that the incomparable Pamela Dingle was moderating. The goal was to go a little more esoteric and explore a little of the cutting edge and future innovations in cloud identity. I know I barely scratched the surface, and I know that some of the misadventures and hiccups of the night before made the session not quite all I wanted it to be. So it was really gratifying to have so many people come up to me and tell me that they enjoyed my talk. And I did manage to get in some solid digs at Paul Madsen, which is always a good thing. I’ve now adapted that talk for all of you to enjoy, filling in some of the details I couldn’t bring out in the talk.

It was a fun talk to create an deliver, as it really got me thinking about some interesting possibilities at the intersection of cloud and identity. And some of it thankfully resonated with some people in the audience (and even one person nowhere near Colorado) that provided running commentary on Twitter, as captured below.

If you have comments on this talk, leave them in the blog comments or tweet them to me at @NishantK. I fully intend to keep exploring this fascinating topic.

Tags: Cloud Computing, Cloud Identity, Cloud Identity Model, Cloud Identity Summit, IDaaS, Identity as a Service, Social Identities

And Identropy will be right there at CIS exploring just how far identity has come and where it can still go.

On Wednesday, July 18 at 11am, I’ll be giving a talk entitled “Ask not what Identity can do for the Cloud, but what Cloud can do for Identity“. In this session, I’ll explore some of the new and innovative capabilities that enterprises and individuals will benefit from thanks to cloud-powered identity and identity management. Because of cloud computing, the world is getting more interconnected, instrumented and intelligent, and this will enable identity to create and deliver value in fundamentally new ways.

Later at 4pm, I’ll join a panel of experts to discuss “Issues and Opportunities for IDaaS“.

And be sure to drop by the Identropy demo station in the solution showcase to see our innovative SCUID solutions for identity management.

See you all in Vail.

Tags: CIS2012, Cloud Identity Summit, Identropy