What Is Cloud Computing?

You’d think this would be easy, given how much everyone is talking about it. But a search on google will show you that there is actually a lot of debate on what the term stands for. Cloud Computing is a fairly elastic term that has been shape-shifting over time to encompass more and more disciplines in the area of IT operations. For a detailed explanation, I would suggest checking out this (free) research paper by the Burton Group. For the purpose of my discussion, I am going with the basic view that Cloud Computing encompasses all those *aaS concepts we have been hearing about for years now that allow every single layer in the architecture of an application (including hardware) to be utilized as a service over the internet:

• SaaS (Software as a Service): through which application services are offered (examples abound like Gmail, Salesforce.com, Zoho)
• PaaS (Platform as a Service): through which application platform/middleware services are offered (like the Google App Engine)
• IaaS (Infrastructure as a Service): through which underlying computing resources like processing,storage and networking are offered (think Amazon’s EC2)

Gartner has said that there are 5 basic attributes of a cloud computing model:

• It is service-based
• It is scalable and elastic
• It shares a pool of resources
• It is metered by use (aka pay-as-you-go)
• It uses internet technologies

Different Types of Clouds

There has also been some controversy around the concept of private clouds, with different folks defining it differently, or even positing that there is no such thing. I think Private Clouds are real and different from traditional data centers, and essentially refer to cloud computing environments dedicated to a single tenant (thereby not adhering to the sharing attribute). The waters get muddied even further when you bring up the concept of Hybrid Clouds. We’ll see how this is relevant later.

What Does This All Mean For Identity?

When we start to think about applications being delivered over the cloud, or enterprises relying on a cloud computing model instead of a data center model, we start to see certain implications for the identity architecture within.

• What is the identity model for these services? Can it co-exist with the enterprises existing identity model?
• Fundamentally, how will the users of these cloud services authenticate? And how will their access rights be managed and enforced?
• Will the cloud services have access to the enterprise identity stores (that are likely not in the cloud)? Is there a integration approach? Is there a replication strategy?
• What security controls exist around the identity data gathered, stored or used by these cloud services? Will they be in compliance with applicable regulations (like jurisdictional regulations on geographic location of data, PCI DSS) and an enterprises internal controls?
• Who (from the service provider side) will have access to the data? How will that be managed?
• How will the enterprises data be effectively segregated in a shared environment?
• What audit controls exist to allow investigation and discovery?

Generally speaking, the reason companies are considering cloud computing is to avoid the expense involved in building or acquiring the infrastructure, and to some extent managing it. However, without paying attention to the security and governance implications, those cost savings will actually evaporate when they either try to retrofit their existing business policies and controls into the cloud environment, or when they have to deal with the fallout from a breach or issue. I think we’ve all seen this particular movie before, so the question is whether we are paying attention to the lessons learnt. Lets talk about this, and examine how externalizing identity is crucial to making cloud computing viable.

Tags: Cloud Computing, Compliance, IaaS, Identity Services, Oracle_IDM, PaaS, SaaS

TechCrunch blogged about Michael Arrington’s twitter account getting verified without appearing to be verified (no one contacted him). This Mashable post may explain how this happened:

…Twitter will look to see if an official channel of the person in question links to his or her Twitter account from a place like an official website.

This is a good model for verifying a channel -  to look at a known official channel to see if it (officially) links to the channel being verified. However, it doesn’t scale beyond the celebrity use case, because the vast majority of users (like me) do not have anything that Twitter will recognize as an official channel. And Twitter will never have the manpower necessary to run an in-person verification program. But is there a clue buried in how Twitter is approaching this to how we could potentially do this at scale?

An emerging discussion in the identity space has been the topic of reputation as the basis of trust (which is what verified accounts are ultimately about). In the Twitter model, the reputation of the account is enhanced 100% because of it being cited on a well-known, officially recognized website. I recently read a Wired article about a new system for ranking/rating scientists based on number of citations as opposed to publications. Twitter has multiple (similar) variables that could potentially be used to calculate the reputation of a twitter account - number of followers, number of retweets, number/nature/participants of conversations (replies).

If these could be used to calculate the reputation of a twitter account, then you could get to the point where you could calculate the trustworthiness of an account. And then the whole “log in with your twitter account” feature that for now is only getting used in blog commenting systems could take on a much more significant role in the identity metasystem.

Tags: Identity Proofing, Personal Identity Management, Reputation Management, Twitter, Twitter Verified Accounts

My tween daughter was entering some sort of online popularity contest. It involved registering yourself as a contestant online with your email address, and then verifying your entry by clicking on a link in a verification email you would receive. I saw my daughter on the site for what I thought was much longer than needed, and then noticed her furiously logging in and out of multiple email accounts.

“How many email accounts do you have?” I asked.

“Oh, I only have 2, but these are the email accounts of my friends. I’m registering them and then confirming their entry for them”.

“Your friends gave you the password for their email accounts?” I asked, horrified.

“Oh yeah! Some of them haven’t used their email in years. We’re all on facebook”.

The implications of this kind of behavior from the future citizens of the web is staggering, to say the least.

Tags: Password Management

As an abstract identity construct, entitlements model whatever it is in an actual system that allows a user to do some well defined thing. As such, it is a fine-grained access management construct, so Ian isn’t wrong about that. But I think Ian’s post misses the power of the entitlement construct, which is what entitlement management products aim to surface.

An entitlement could simply be the permission to access a URL (typical web access management scenario). It could be the permission to click on a menu item in an application (typical application functional security scenario). It could be the permission to access a particular data record in the database (typical data security scenario). Each of these taken individually is a pretty big deal in of itself, but can be handled by products or features that are already available today.

But in a service-oriented world, where multiple applications get chained together to perform the functions behind a single action a user can perform, the entitlement becomes a hugely important construct. Currently, this would require ensuring that the permissions within every single component are properly coordinated to allow this flow to go off without a hitch. It becomes a very complicated permission engineering problem to figure out how the ensure that the function will work in all cases necessary.

Entitlements provides an abstraction and layer of indirection that eases the problem, unifying the access control equation. In an entitlement management based architecture each service, every tier within the service, every layer within the application, can refer back to the same entitlement and entitlement policy to determine whether or not to allow the function to proceed.

And to provide this kind of cross-service access control, an Entitlement Management product like Oracle Entitlements Server provides the ability to define powerful entitlement policies based on identity, role and contextual data. And while XACML is a necessary part of the architecture that enables a complex deployment to occur, it is just an enabling tool, not what defines the feature itself. In fact, XACML does bring its own limitations to a run-time environment.

Entitlement Management is a powerful tool that can simplify the mess of permissions and privileges that are strewn all over the enterprise landscape. When applications were silos, it was sufficient to deploy a provisioning system that could handle the provisioning of access into these black boxes. But with applications transforming into services and becoming increasingly interconnected and interdependent, role and entitlement management become critical pieces of enterprise architecture that help provide critical control, predictability and uniformity to the enterprise.

Tags: Entitlement Management, Identity Services, Oracle_IDM, Service-Oriented Security

Twitter Search will also get a “reputation” ranking system soon, Jayaram told me. When you do a search on a “trending” topic–a topic that is so big it gets its own link in the Twitter.com sidebar–Twitter will take into account the reputation of the person who wrote each tweet and rank the search results in part based on that.

The article does mention that the engineering team at Twitter is still trying to figure out how to do this. But no more than a day later, Stan Schroeder of Mashable pointed out one of the key aspects to making reputation work - it has to be context-sensitive with respect to the identity of the source and their authority on the subject.

Thinking about it, it seems that this reputation ranking system is far more complex than a simple combination of factors such as followers and retweets. The system needs to be contextual; it needs to recognize which tweeple are important for a certain keyword or phrase. For example, tweets from the White House, Barack Obama and politicians aren’t that useful in the context of a Gmail outage, but they’re crucial during some political event.

In other words, the reputation engine (if it is to be done right) can’t just look at the number of followers, the number of retweets and hashtags. It also can’t rely purely on the 140 character biography that all the tweeples have posted on their twitter profiles. No, to really do this thing justice, Twitter (or some other company that could step in) would need to navigate the semantic, social and identity web in a way that builds up an accurate picture of a persons authority regarding a particular subject. And it is not just based on what we put out there, but even more so on what others put out there in response.

If this feels like somebody is about to start building a credit score of our online lives, it isn’t too far off the mark. The implications in the area of personal identity management and privacy could be huge!

This highlights a change we are seeing in the personal identity space. Since there are no secrets any more (as Bob Blakley is wont to remind us every now and then), relationships and reputation are likely to become the primary variables in the identity equation. The question therefore is, what tools do we need to manage and control our online identity in light of this new perspective on identity? Is it simply about having an OpenID and clean living? What tools do the social networks like Facebook and LinkedIn need to incorporate that give us control over not just what we put out there, but what others put out there about us? It’s a tough nut to crack, and should make for some interesting discussions at IIW next week. Maybe I’ll throw it up there on the board as a topic.

Tags: Personal Identity Management, Relationship Management, Reputation Management, Twitter, Twitter Search, User-Centric Identity

But it is partly also because I have been working on migrating my blog from Oracle’s blog infrastructure (known to insiders as BOC) to a self-hosted wordpress install. The new home for my blog is http://blog.talkingidentity.com/. The reasons for my move are far too many to go into, but I do hope that the move enables me to get more engaged with my readers.

If you are seeing this post in your blog reader, then you don’t need to do anything. You are subscribed to my feedburner feed (smart), and it will continue to work for you (let me know if it doesn’t). I apologize for the spam this may have caused in resending my last 10 posts into your blog reader. Just go ahead and mark them all as read (I won’t mind), and wait for the next insightful, witty post to come your way. I look forward to using my shiny new toy as I continue talking with you about identity.

Computer scientists Arvind Narayanan and Dr Vitaly Shmatikov have proven that the anonymized data sets that social sites sell to marketing firms are not really that anonymous. It is possible to reverse engineer these data sets and obtain actual names and addresses, by looking at the content and structure of the data (in their example, correlating data from Twitter with Flickr).

• BBC Coverage
• Detailed look by Ars Technica
• The paper: De-anonymizing Social Networks

This raises grave concerns about a practice that has becoming increasingly common as social networking sites seek ways to monetize their data. They routinely release social graphs from which a few bits of personally identifiable information (PII) has been stripped to interested parties - advertisers, third-party apps, government and academic researchers. Conventional thinking is that this is good enough to protect people’s identities.

But as the paper shows, this is nowhere near good enough. It’s an interesting study that essentially redefines the term PII, and could (should) have grave implications for social networks and their responsibility towards their users.

The lesson, as Ars Technica points out, is that “anonymity is not sufficient for privacy on the web”.

Tags: PII, Privacy, Social Graph, Social Networking

Pat’s post is definitely worth a read as it describes how Liberty Alliance has proposed a solution to the thorny issue of data exchange between the two parties in the case of Scenario 2: Just-In-Time Provisioning. It sounds like an elegant solution, especially since it solves the issue Karl brings up in the comments to my post regarding not overloading the SAML assertion with extraneous information. Would love to hear if anyone knows of any issues in the solution.

Ian and Pamela also discuss the issue of federated de-provisioning, which has also been a thorny issue in federation discussions. Pam talks about being able to initiate de-provisioning when a user who should no longer have access tries to authenticate. That is certainly one way to do it. But more often than not, de-provisioning cannot be initiated during an authentication flow because the reason the user should no longer have access is that they are no longer employed at the company they got federated from. Meaning: they cannot authenticate from the RP in the first place.

What harm then, is there in a federated account sitting around if it cannot be authenticated to? Well, the answer I usually get (from customers) is that in the reality of today’s systems, creating federated access to a service often involves creating some sort of account in an underlying legacy system. An account that can be authenticated to outside of the federation context, albeit only from a back-channel. While this is a scenario less likely to get abused, it is nonetheless a scenario that security audits frown upon, and that get flagged for remediation as a compliance risk.

So what to do? Ian talks about expiring accounts that have not been accessed in a while. Out-of-band de-provisioning between the RP and the SP is also a possible option, as described by Pam. That makes the overall integration between Acme and Omega a blend of Scenario 1 and 2, where federated provisioning happens just-in-time, but de-provisioning happens out-of-band (probably on a periodic basis) through a well-defined interaction. The de-provisioning can be made real-time as well, in that the provisioning server at Acme can issue a de-provisioning SPML request to the provisioning server at Omega, just like it would to any internal system, when the user is de-provisioned at Acme.

As you can see, solutions abound, and customers can choose the one that suits their needs the best. So it is pretty obvious that it is possible to solve the federated provisioning/de-provisioning problem. The issue is that none of this is standardized or formally productized in any way, and is left as an exercise for the customer to solve (Translation: Costly integration problems when different vendor products are involved). And where this issue was a costly annoyance in federation deployments between businesses, SaaS (where this whole discussion started) takes this to a whole new level, creating a barrier for adoption.

But as Pat says “Seems like that might change now…”

Tags: Federated Provisioning, Provisioning

Suppose two companies, Acme and Omega enter into a federation agreement, whereby employees of Acme will be able to access a service at Omega using their Acme credentials. There are two scenarios here for federated provisioning.

Scenario 1: Advance Provisioning

Acme decides that they will decide beforehand which employees are allowed to access Omegas service (based on business rules or approved requests). They will therefore do some advance work sending provisioning requests to Omega for those employees that are to have access, allowing Omega to set up federated accounts (with the appropriate mappings) for those employees. A lot of times today, this is done in the form of a batch file/spreadsheet/LDIF file containing all the users that should have access going from Acme to Omega. In an ideal situation, this would be handled by Acme’s provisioning engine sending SPML-based provisioning requests to Omegas provisioning engine.

This is the scenario that Ian is referring to when he says that federated provisioning is no different than regular provisioning, and he’s right. As a provisioning target, Omegas service is no different from a sensitive target within Acmes own boundary (the logistics of setting up the trust may be a little harder). And whether or not the service is SPML-enabled or not really doesn’t change the problem statement.

However, there is another scenario that changes the discussion a bit.

Scenario 2: Just-In-Time Provisioning

Acme decides that they are not going to decide beforehand which employees are allowed to access Omegas service. Instead, a link to the service is available on Acmes intranet, and whenever a user decides to go to the service, they should be given an account. In this case, no pre-provisioning is taking place. Instead, the provisioning has to occur in real-time, when the user accesses the service via the intranet link for the very first time.

The idea here is that when Omegas federation server encounters the incoming SAML token for a new user, it would recognize that the user does not have a federated account, and send the SAML token to Omegas provisioning server. The provisioning server would create the account right then and there, and return the necessary result back to the federation server so that the federation server can proceed to grant the user access.

This scenario is much more complicated than scenario 1 because of multiple dimensions. First off, the interaction between the federation server and the provisioning server has to be responsive and well-defined (and to prevent vendor lock-in, standards-based). An added wrinkle may be that the federation server may need to collect additional user information not available from the SAML token, in order to provide the complete set of information necessary to provision an account to the provisioning server (an alternative could involve a handoff to the provisioning servers self-registration screens to do the same). And the provisioning server needs to be able to understand the needs of the federation server with respect to provisioning and responses. I won’t even go into the need for cache invalidation, etc.

This is where federated provisioning is not like regular provisioning (as we know it today). There are a number of things needed here that regular provisioning isn’t set up for. The standards-based interaction between the federation server and the provisioning server isn’t defined today, and SPML is not set up to accept SAML tokens as data inputs, or handle the just-in-time nature of this scenario. This is where a lot of work still needs to be done.

I would be interested in hearing if anyone has done anything to do with scenario 2. And, of course, any dissenting opinions on the matter (Ian?).

Tags: Federated Provisioning, Provisioning

Privacy is a funny thing - most people assume they have it unless they explicitly do something to give it up, but in actuality, information about us is flowing all over the place without our knowing it. As Bob Blakley likes to say, “There are no secrets”. In the US (which is yet to ratify this convention), data about individuals is a commodity at the heart of many a business. And advancements in technology have opened the floodgates, with many of us contributing to the flow through our usage of social media. I’ve lost track of the number of articles I have read warning college students of the impact their Facebook activities could have on their job searches. Asking individuals to basically shrink away from communities in order to protect their privacy is not the right answer. We need to do more to enable privacy.

In honor of International Privacy Day, I thought I’d post a few links that provide some (essential/interesting/weird/amusing) perspectives and information on the topic of privacy as it is being talked about today.

• Proposed “Camera Phone Predator Alert” bill would require all cameraphones to make themselves heard
• One Man’s Experiment With a Location-Aware Lifestyle: An interesting post from the blog of the Privacy Commissioner of Canada
• More information on Data Privacy Day, thanks to Intel (see this interview with David Hoffman, Director of Security Policy and Global Privacy Officer at Intel as well)
• In the United States, the US Privacy Coalition (including EPIC) is launching a campaign to urge the US government to support the Council of Europe Privacy Convention
• Search Privacy Issue Goes Mobile
• Forrester Research Making the case for Data Masking
• A Move Toward More Privacy Online: Yahoo changes data retention policies
• Identity Governance Framework at Liberty Alliance
• Data Privacy Day Exhibit Differences in Approach from Google and Yahoo

If you are doing anything for International Privacy Day (and it isn’t private! - thanks @trevcook), or have links to interesting stories regarding privacy, please leave me some comments. And be sure to pass on the word. Request your government to support the Council of Europe Convention on Data Protection (No. 108) and to adopt comprehensive privacy legislation based on that standard.

Tags: Identity Governance Framework, IGF, International Data Privacy Day, International Privacy Day, Privacy