Fired Up About the Kindle Fire

A couple of months ago, I wondered whether I had any use for a Kindle Fire, and concluded that while it was an intriguing device, I probably didn't need another tablet in my life. Well, it turns out I was wrong. A few days ago, Santa came early with an Amazon "smiley box" containing a brand new Fire. Within ten minutes of ripping open the box, I was hooked.

I've owned an original iPad for over a year now, and use it mainly for watching movies on planes, reading eBooks on the Kindle app, playing Angry Birds when I need to take out my frustration on defenseless cartoon piglets, watching streaming media on Netflix, Hulu and SlingPlayer while on the road, and taking notes in meetings. The iPad hasn't quite replaced the need for a laptop yet, but I've certainly made good use of it. So it never occurred to me that there was room in my gadget-filled life for another tablet. That was, until I opened the smiley box.

Like the iPad, the Fire "just works" out of the box. No instructions are needed, there are no complicated setup procedures; you just turn it on and go. If you don't know what the Kindle Fire is for, the simple home screen menu says it all (Music, Video, Apps, Books, Newsstand, Docs, Web). No ambiguity there. Simply go through a simple Wi-Fi configuration screen, enter your Amazon ID to register the device, and you immediately have a wealth of media at your fingertips.

Make no mistake, media consumption is what the Kindle Fire is all about; specifically, consumption of media from the Amazon ecosystem. The first thing that impressed me was that every streaming movie I have ever purchased from Amazon (usually through my TiVo box) was immediately available in my Video library. I'd forgotten that on a cold, rainy day about five years ago, I'd paid ten bucks to stream Love Actually from Amazon (don't say a word!), but there it was, sitting right in the library.

Needless to say, every eBook I'd ever purchased on my iPad Kindle app was also there. And I quickly discovered that by connecting the Kindle Fire to the USB port on my laptop, I could transfer MP4 movies to the device for subsequent viewing. Yes, I know the iPad also allows you to do that, but the Fire doesn't require a clumsy, heavyweight app like iTunes to synchronize files; it operates just like a flash drive, so transferring media is simply a matter of copy and paste. Gotta love that!

The OS is based on a custom implementation of Android 2.3 Gingerbread. While it is heavily "Amazonized", there is no hiding the fact that an Android kernel lurks under the hood, and I don't necessarily mean that in a good way. No matter how much you try to put lipstick on that Angry Birds character, Android lacks the polish, elegance and responsiveness of iOS. Functionally, it works great, but if you have been spoiled by iOS, the jerky scrolling and occasionally erratic keyboard can get a little tiresome.

Perhaps the weakest feature of the Fire is the Silk web browser, which I found to be painfully slow, especially when loading Javascript-intensive webpages. Granted, the iOS implementation of Safari is no speed demon, but compared to Silk, it is like putting a Formula 1 car up against a 1987 Chevy Nova. I'm not sure whether this is due to the Silk application itself or the Fire's low-end hardware spec, but considering that the Fire packs a not-too-shabby dual-core OMAP 4 1GhZ processor, I suspect it has more to do with the former.

I found it strange that the home screen menu does not contain a link for email; instead, the email client is buried under Apps. The email client offers a basic set of functionality but does what it is designed to do and worked fine with my work and personal GMail accounts, aggregating all of my mail into a "Unified Inbox". In many ways, I prefer it to the iOS mail client.

Speaking of apps, the Amazon App Store offers a surprisingly large and growing range of them. Within minutes of opening the device, I had installed Netflix, Pandora, Facebook and Hulu Plus. There wasn't a Kindle version of SlingPlayer yet, but I was able to obtain the generic SlingPlayer app for Android and then install the package using the ES File Explorer app. Simple. And yes, Angry Birds is available too.

So what of the device itself? Given that my tablet experience so far has been limited to the 9.7" iPad, I found the 7" form factor of the Kindle Fire refreshing. There is something nice about being able to comfortably hold a tablet in one hand, particularly when reading an eBook or magazine. Strangely, the smaller form factor isn't as constraining as I expected it to be; writing emails using the onscreen keyboard is no more cumbersome on the Fire than on the iPad. If anything, it is slightly easier, since the 7" form factor allows you to thumb-type in much the same way as one would on a smartphone.

The most pleasant surprise was the display, which I expected to be slightly below par given the Fire's price point. Colors are rich and vivid, contrast is outstanding, and videos are razor sharp. Some may disagree, but the Fire's display is more than a match for the iPad. And the embedded speakers are, if anything, superior to those on the iPad with a slightly broader volume range and less tinniness.

That is not to say the Kindle Fire is perfect, by any means. The omission of volume buttons is extremely puzzling, given that the device was clearly designed for media consumption. To compound matters, the onscreen volume slider is always in a different place depending on the app you are using. As for capacity, the miniscule 8Gb storage doesn't offer much room to store music or videos. Yes, I know that Amazon's cloud infrastructure theoretically reduces the need to "store" media, which is fine if you always have a Wi-Fi connection. But for a road warrior like me, Wi-Fi isn't always an option. Not all planes are Wi-Fi enabled, and have you ever tried streaming media using a hotel Wi-Fi connection? Still, the lack of storage isn't a dealbreaker, given how easy it is to transfer files back and forth over USB.

If the Kindle Fire were priced similarly to the iPad, any of these shortcomings would be enormous. But it isn't, not by a long shot, and that is the point. Given the Kindle Fire's $199 price tag, what might be fatal shortcomings for an iPad or similarly priced tablet are trivial gripes in this case.

But the real test for me is how frequently will I use the Fire compared to the iPad. Well, after two weeks with the Fire, I've learned that it depends on the use case. If you read a lot of eBooks and eMagazines, then the Kindle Fire is a superior option given its weight and form factor. For movies, there isn't much to choose between the two; the Fire is great if you don't mind a slightly smaller screen, and it compensates for this with superior sound quality. Given those two factors alone, I have found myself more inclined to use the Fire when on a plane, grabbing a latte at Starbucks, or just catching up on some late night reading.

But the Fire isn't a productivity device like the iPad. I could not imagine myself using it to take meeting notes, fire up a quick spreadsheet, edit a slide deck or even act as an RDP thin client to access my remote servers. Then again, Amazon didn't design the Kindle Fire to be a productivity device. They clearly built it to provide a portal into the Amazon media ecosystem. The device ships with a free 30-day subscription to Amazon Prime, which in addition to free two-day shipping, provides access to a range of free streaming movies and TV shows. While this library isn't as extensive as that of Netflix, it seems to be growing rapidly and you also have the option of renting or purchasing more recent movies directly from the device.

So just when I thought I had all the gadgets and devices in my life that I could handle, the Kindle Fire has found a niche that I didn't even know existed. I may not have needed one, but iPad or not, I will certainly make good use of it. Even had it not been a Christmas present, the $199 price tag is a bargain. For consumers who want a tablet but cannot justify the $499 entry point for an iPad, the Kindle Fire offers a compelling alternative. It may be less than half the price of an entry-level iPad 2, but certainly offers more than half the functionality and features.

Gartner 2011 Magic Quadrant for IAG: Tight Competition in a Maturing Industry

Gartner has just released its first ever Magic Quadrant for Identity and Access Governance (IAG), and SailPoint appears to have emerged as a narrow victor. Unlike the Forrester Wave for IAG published earlier this year, which showed SailPoint and Aveksa leading the competition by a mile, Gartner has 4 of the 7 evaluated offerings in the top quadrant, with CA on the borderline.

Admittedly, I'm more familiar with SailPoint IdentityIQ and Oracle Identity Analytics than any of the other products featured here. Both are extremely mature, versatile offerings that are simple to deploy and provide a full range of access governance capabilities, including role analytics, detective/preventative policy enforcement and certification/remediation. From a pure governance perspective, there isn't much to choose between them.

SailPoint's acquisition of BMC's identity management offering and their incorporation of BMC's provisioning engine into IdentityIQ means that they are no longer a pure play IAG vendor, and can compete on equal terms in the IAM space with the likes of IBM, Oracle, CA and Microsoft. In recent months, SailPoint has also been adding provisioning capabilities to their extensive range of native governance connectors, which ship with the product. Of course, OIA also offers provisioning capabilities, but only when integrated with OIM or another supported provisioning product.

As I've noted before, the maturation of identity management is driving a trend away from bottom-up identity administration tools, towards more holistic, governance-based solutions. Visionaries such as SailPoint have long anticipated this evolution and are ideally positioned to take advantage of it as organizations become more sophisticated in how they approach identity governance.

The decision by both Forrester and Gartner to begin publishing IAG market analytics in 2011 acknowledges the increasing maturity of IAG. The explosive growth being experienced by Aveksa and SailPoint offers further validation, if any were needed, of this trend.

The question is, what does this mean for identity management practitioners?

Well, as one might expect, there is good news and bad news. The bad news is that it is no longer sufficient to be a technical whizz who can develop advanced customizations, custom connectors and sophisticated workflows in their product of choice. As IAM/IAG offerings become easier to deploy, offer richer, more business-friendly functionality, and adopt a less I.T.-centric approach, I expect the demand for advanced technical customizations to diminish. The good news is that the increasing maturity of these offerings will allow identity management professionals to spend less time focusing on arcane technical integrations and more time devising robust, governance-centric solutions for customers.

I'm not saying that the market for identity administration tools will go away. Of course it won't; there will always be a demand for automated provisioning. But identity administration is becoming more commoditized, and over time I expect it to be increasingly viewed as just one component of a more holistic IAG framework. Just because the tools are becoming more sophisticated doesn't mean that the operational challenges that create a need for streamlined identity administration are going away.

The real implication is that IAM/IAG solutions are evolving from mere I.T. tools into corporate governance suites, which in turn suggests that the target audience for such offerings is increasingly likely to be a CTO, CISO or CIO than the Manager of Enterprise Applications. For identity management professionals, this means that the ability to articulate business value to a non-technical audience, deliver policy-driven solutions and demonstrate a sophisticated awareness of the regulatory landscape will become just as important as the ability to create a kick-ass workflow. Individuals with that balance of soft and hard skills are difficult to find, and will therefore remain in extremely high demand.

Which, in my opinion, is exactly how it should be.

Access Rights versus Access Usage

Having been in the IAM space for enough years to remember when the idea of a metadirectory was still "cool", I spend a lot of time thinking about where the industry is going, and more specifically, how we can enhance the value that IAM brings to our customers. Recently, one such customer articulated a requirement for an identity governance solution that not only provided them with a global view of access privileges, but allowed them to see who was accessing a particular server or file share.

It occurred to me that most modern identity solutions do a great job of providing a view into who has access to what, but not what they are actually doing with that access. These are two completely different concepts, but from a technical perspective, they don't necessarily need to be.

A standard identity management suite ships with a connector framework that exposes a common interface to abstract the logic that interacts with the target system. These interactions generally comprise standard IdM events such as account creation, modification, enablement, disablement, retrieval and deletion. Obviously, each connector "type" is required to invoke native API calls.

Since vendors are already building connectors that manage accounts across a wide range of target systems, how difficult would it be to extend these connectors to inspect logs on those same systems, and then correlate each log entry to an identity object in the same way that we already do for native accounts? For example, in addition to pulling a list of local accounts from a UNIX server and correlating them to a person's identity, a UNIX connector could expose a method to pull the server logs and update identity records with information about what actions each user had been performing on that server.

It's just a thought, but it strikes me that being able to see who is doing what is as foundational to robust identity governance as being able to see who has access to what.

More Thoughts on Cloud Identity

Unfortunately, I haven't had much time to blog lately, as November was essentially a wash. First, we were left without power for a couple of weeks by the epic Halloween storm that crippled much of New England early in the month. Then I took off on my annual pilgrimage to visit relatives in England. And then, of course, it was Thanksgiving. Next thing I know, the malls are filled with Christmas shoppers and the drone of those annoying seasonal tunes to which we are thankfully subjected for only a few weeks a year.

Anyway, I'm back now. While catching up on my favorite blogs, this comment on cloud-based identity by Sean O'Neill---who I consider to be one of the best minds in the business---caught my eye, mainly because it echoes my own sentiments on the topic.

Sean notes that from a technical perspective, there is nothing earth-shatteringly new about cloud computing itself, except that we now give it a fancy name. No argument from me there. But his more important point is that the increasing adoption of cloud services creates a whole new set of governance headaches for CIOs. To illustrate this point, he quotes the CIO of a major insurance company:

“One thing I have come to realize is that when I move my application to the cloud, all of the security of my networks and firewalls that I have invested in over the years disappears. The only defense I have left is identity and data security in the application”

In my experience, that sentiment is probably not unusual among CIOs and CISOs, particularly in highly regulated verticals such as financial services, pharmaceuticals and healthcare. Entrusting identity management to the cloud may seem like a good idea to analysts, vendors and techies, but they are not the ones who would be laying awake at night, worrying about the legal and regulatory implications of their cloud identity provider suffering a catastrophic breach.

As Sean explains:

Even if you can sue the pants off of your cloud provider, the basic problem is a breach would have occurred and your people are not involved at the security level.

In other words, if you are a CIO and sensitive personal information about your customers and employees is leaked due to a breach at a third-party identity provider, the victims aren't going to give you a pass because you entrusted security to a cloud service. If anything, they will hold you even more liable for gross negligence. Not to mention that "not my fault" will do nothing to mitigate damage to your company's brand reputation.

The increased adoption of cloud computing is inevitable, but it is both reckless and unrealistic to view IAM as just another one of those services, particularly for large organizations.

Currently, everybody seems to be focused on the idea of moving IAM tools to the cloud (which, by the way, does nothing to alleviate the process and governance issues that make IAM projects so notoriously complex---it simply moves these problems somewhere else). Instead of viewing IAM as just another commodity, we should be thinking about how to help organizations evolve robust governance strategies for managing cloud identities. I know this isn't as sexy as the idea of cloud-based IAM products, but it is far more relevant to the average CIO.

Is Logical/Physical Convergence the Next Big Thing in IAM?

Traditional identity and access management describes the processes, systems and policies that are used to identify individuals to information systems, control what privileges they have, and what they are doing with those privileges. By now, this is all well understood.

But why should IAM be restricted only to systems? For most large organizations, the need to control physical access to secure facilities and locations is every bit as relevant to a holistic security strategy as controlling access to applications and data. Corporations spend millions of dollars on physical security systems such as CCTV, electronic barriers and identification cards, designed to prevent unauthorized personnel from accessing restricted areas. Typically, these systems are centrally managed by a Corporate Security department, so that individuals are only granted the physical access required of their jobs, and any attempted security breaches can be immediately detected.

You see where I'm going with this, right? Conceptually, physical security represents the most basic IAM use case. One could almost think of buildings as applications and areas within those buildings as fine-grained entitlements, and the paradigm for physical security is identical to that of I.T. security. Once you make that connection, there is no reason why physical security could not be assigned using RBAC. Indeed, most commercial physical security systems already provide for role-based access.

Yet, for some inexplicable reason, physical and logical security are still generally viewed as two separate disciplines, which makes no sense to me. I suspect this is because in most organizations, I.T. Security and Corporate Security are distinct organizations, and there is often very little cross-pollenation between the two. IAM vendors, for their part, clearly haven't felt any pressing need to address this gap, and still focus almost exclusively on managing access to I.T. systems.

Some of the advantages to logical/physical convergence seem glaringly obvious:

• Reduced TCO achieved by centralized management of all access policies, instead of having to maintain separate systems and processes for logical and physical access.
• Greater compliance with regulatory mandates such as HSPD-12, GLBA, SOX and FIPS-201.
• Streamlined offboarding processes, which is particularly important when dealing with a sensitive termination scenario.
• Smartcards can serve a dual purpose of granting physical access to corporate facilities and providing a second factor of authentication to sensitive systems and data.

Of course, a converged IAM offering would need to be sold in a different manner from traditional IAM solutions. In many cases, IAM products are pitched at the Director/VP level of an I.T. organization, and sometimes at an even lower level than that, particularly when the solution is being acquired to address an urgent tactical need. But only a CIO, CEO, CTO or CCO usually has the appropriate authority over both I.T. and Corporate Security to appreciate the value of a converged offering, and has the political muscle to mandate its implementation. This is yet another reason, as I've argued before, why IAM needs to be positioned more as a corporate governance asset than a back-office I.T. function.

From a technical standpoint, supporting logical/physical convergence should not require a significant re-engineering effort for most IAM vendors. So I find myself asking, why hasn't this happened so far, and who will be the first to address the gap?

Is SPML Really Dead?

Over the past year or two, there has been an intense debate in the IAM community about the future viability of SPML. This began with a blog post by Burton Group's Mark Diodati in February 2010, in which he offered a bearish perspective on the poorly adopted provisioning standard.

I agree with many of the points Mark raised. Yes, SPML is too complex in its current incarnation. In trying to offer a broad range of functionality and account for every conceivable provisioning scenario, it often ends up accomplishing quite the opposite. Accordingly, SPML implementations tend to be extremely product specific, which defeats the entire purpose of a common standard in the first place. He is also correct that SPML implementations often cause performance issues due to the burden they place on connectors, although I would argue that this is less attributable to the standard itself than to how SPML has been implemented by provisioning vendors. And I completely agree with his assertion that enhancing the standard with a common inetorgperson-like user schema such as "SPMLPerson" would not only promote greater convergence with SAML, but would lead to increased adoption in the enterprise.

With that said, SPML works extremely well when implementations avoid connector-heavy and product-specific customizations (I'll come back to that shortly). In my opinion, the lack of SPML adoption isn't just because the standard itself is deficient, but because nobody has quite figured out the best way to implement SPML interfaces.

The most common use case I've encountered for SPML is when a customer wants to integrate their own proprietary UI with a commercial provisioning system. For instance, one of my customers has a sophisticated, AJAX-enabled access request portal built in .NET. It provides all the workflow functionality that one would expect to find in a commercial provisioning system, but was designed simply to manage requests and approvals rather than to automate provisioning. The customer had acquired Sun Identity Manager for provisioning automation, but didn't want to replace their elaborate, business friendly .NET interface with SIM's antiquated UI (and who can blame them?) In this particular instance, SPML was the obvious solution. The .NET application was modified to simply fire off SPML requests to SIM on the backend, thus automating provisioning actions while protecting end users from any visible impact.

In scenarios such as this, where a homegrown access request portal needs to integrate with a provisioning system, SPML works like a charm. But let's face it, this scenario doesn't require SPML specifically. In the use case I just described, Sun Identity Manager could have exposed any old SOAP or REST interface, and the integration would have been exactly the same, providing that the interface exposed the requisite methods.

The true value of a standard such as SPML is realized when providing interoperability with enterprise or cloud applications, and this is where SPML has unequivocally failed to deliver.

Which brings us back to the problem with SPML implementations. Because the standard is so broad and, unlike SAML, fails to define even a minimal schema for user profiles---much less offer a reference implementation---identity vendors have tended to implement variations of SPML that are product specific and are tightly coupled with the connector layer and underlying data stores. The result is that most SPML implementations are ugly and XML-heavy, which in turn can lead to performance issues when performing large numbers of provisioning transactions.

I have yet to see an SaaS application that supports inbound SPML messages in a way that could be called "standard". Likewise, I have yet to see a user provisioning solution that supports SPML in a non-proprietary fashion. As a result, provisioning solutions for cloud applications still depend heavily on individual connectors that all implement different product APIs, which is to say that SaaS applications are currently treated no differently from any other kind of application.

So the question remains, is SPML really dead? Well, in its current incarnation, it's hard to argue that it was ever really alive to begin with. SPML 2.0 is now five years old, and the OASIS Provisioning Services Technical Committee hasn't convened since 2008. But the critical need for interoperable provisioning is now greater than ever, particularly considering the explosive adoption of cloud applications in recent years. The fact that most identity management RFPs include a requirement for SPML confirms that standards-based integration remains a critical priority for organizations. Even as IAM maturation drives us away from traditional user-centric IAM towards more business-centric models, identity management projects still spend far too much time focusing on provisioning, and specifically on the nuances of proprietary connector architectures; this is another argument for a widely adopted provisioning standard that abstracts the complexity of underlying systems and data stores.

If SPML is to survive, then it will have to be reincarnated without any consideration to backwards compatibility. For that to happen, a major player in the identity space (I'm talking about the likes of Oracle, CA or IBM here) needs to step up, take leadership and create some momentum for a new standard.

In the meantime, there are several proposals out there to compensate for the lack of momentum surrounding SPML and the critical needs that it was intended to address. Jim McGovern, never a shrinking violet, has a wish list for what he would expect to see from SPML 3.0, if it ever happens. In 2009, the visionary Nishant Kaushik proposed using OAuth to support federated provisioning needs. The SimpleCloud (SCIM) initiative----which enjoys participation from various cloud providers such as Google, Salesforce as well as identity vendors such as UnboundID and SailPoint----appears to have embraced this concept and taken it to another level. For my money, SCIM is the most promising candidate for a new provisioning standard. Seemingly inspired by the LDAP standard, SCIM also leverages SAML, OAuth 2.0 bearer tokens, OpenID and JWT, while favoring a REST API over less efficient SOAP.

In summary, I tend to agree with Mark Diodati that SPML in its current form is obsolete, but the need for an interoperability standard is now greater than ever. Two lingering questions remain. Will SCIM be the standard we've been waiting for, and what is the value proposition that will compel vendors to embrace it?

A Brief Recap on OpenWorld 2011

Well, my intentions were good, at least. I had intended to blog throughout the week from Oracle OpenWorld, but ended up being so busy (this is the first year that we have had a booth at OOW), I never had time to post anything. The event itself was even bigger than last year, with more than 45,000 attendees and 4,500 Oracle partners.

Although I didn't get to attend any sessions due to other commitments, I'm planning to download and watch the sessions of interest later. In the meantime, here are a few things that we learned this week:

• Oracle seems committed to nurturing and expanding a flourishing partner network, and appears to have no interest in providing services.
• Larry Ellison's keynote received, let's just say, a lukewarm reception. The spat between Larry and Salesforce CEO Marc Benioff cast something of a dark shadow over proceedings, especially when the former referred to Salesforce as a "roach motel". Of course, all of this pointless bickering was put into stark perspective when it peaked on the same day that Steve Jobs passed away.
• The Public Cloud is core to Oracle's vision of providing subscription-based access to business applications, including the Fusion middleware stack.
• Oracle's first partner preview of Solaris 11 proves that my favorite *nix O/S is still alive and kicking, nearly two years after the Sun acquisition (yay!). Solaris 11 is fully virtualized, contains an impressive range of performance and functionality enhancements
• The Oracle Big Data Appliance (BDA) is a BFD!
• From an IAM perspective, not much to report, although admittedly I haven't watched the IAM sessions yet. There doesn't appear to have been much movement in this space since last year. Frankly, given Oracle's size and ambition, IAM appears to be losing some relevance for them. I hope I'm wrong about that.

There is no ambiguity about Larry's Oracle's technology vision. It can be summed up in three simple phrases: Big Data, Cloud and Parallel Processing.

Conference weeks always leave me feeling drained and needing a few days to recover. So I'm spending the weekend in Venice Beach, where I will NOT be thinking about Exadata or anything else to do with technology for the next couple of days.

Have a great weekend everyone!