Welcome back from the holidays.

Been busy around here with getting ready to join Oracle (granted, its an acquisition, but in the end, I can choose to accept a position, if offered).  Oh, and lets get the 2010 thing out of the way (its twenty-ten, just like nineteen sixty three, not twenty-ought-ten). And remember back in 1984?  This was the year Arthur C. Clarke said we would make contact. Let me know how that works out for you.

So were do we stand looking forward to the new year?  That’s been a focus of mine recently and quite a few others out there.  Central repositories – been there, upgraded that.  Access Management – transitional year as it takes on more significance, but not the big mover this year.  Provisioning – deployed, upgraded, and looking to reach deeper into the organization (more on this in a future blog).  Role Management – good stuff, good market, and tools maturing.

My personal focus is on entitlements this year. Its their time.  To date, all identity projects really have eventually dealt with entitlements – who has access to what and what can they do with it.  But we never have really gotten down to where the “rubber meets the road”. The actual security attributes on a resource (files, dbs, ports, devices, sockets, pipes, queues, applications, etc.) can be many and numerous.

Accounts have entitlements and roles are a way of grouping accounts and entitlements into a more manageable form.  Accounts and roles have full life cycle management. They are defined, approved, deployed, certified, and retired. As such,we have been managing entitlements all along. But now, specific life cycle management of the entitlements themselves is being asked for.  For example, the specific entitlement “transfer up to $100K to a vendor” will need to be identified as critical to the organization, will need an owner, will need to have a regular certification cycles, and will need to be fully life cycled. Not the account, not the role, but the entitlement specifically.

So how big is this elephant?

Take Solaris’ file system.  Many think there are four entitlements to the file (read, write, execute, denied). But they are combined into eight permissions (No permissions, execute only, write only, write/execute, read only, read/write, read/execute, read/write/execute).  And these permissions are grouped into three permission sets based on who is trying to access the file – owner, group, and other.  This leads to actually:

8 owner X 8 group X 8 other = 512 permission possibilities on file

Now add the fact the file resides somewhere inside a directory that has its own set of permissions:

512 file permissions X 512 directory permissions = 262,144  permission combinations

So every file has over a quarter of a million ways of securing access to it. Granted having full permissions to a file in a directory that has no permissions is a little self defeating (actually, it is meant to defeat unauthorized access), you get the idea of how quickly entitlements management can get out of hand.

Add to that ERP GRC, SOA web services entitlement, and the need to expand identity to virtual and federated resources and you may start to understand the gravity of the situation.

So, we are going to start this year focusing on entitlement management in the next few blogs, if for no other reason to scare the pants off of anyone who currently works in the identity field.

Be seeing you.

MSI had several concept products on display at CES 2010. Here are digital stills of the products. Enjoy!

Below is MSI’s concept E-Book device featuring a 10 inch touch-screen display, and support for WLAN/Wi-Fi/3G connectivity.

 

Below is the MSI 3D All-in-One desktop PC.

Below is the MSI Jellow All-In-One Family PC.

Below is an MSI dual-screen notebook PC featuring a 10 inch dual touch-panel with virtual keyboard and e-book experience.  Runs Windows 7 OS.

Two days from an
important Google announcement, privacy
awareness is steadily increasing in the media. The old
mantra that “despotic governments might use your data in unexpected
way” sounds more real than last week, and recent movies ring
different bells in our heads.

That event has prodded me to (finally!) blog about
yet another eclectic paper of mine, co-authored with my old
friend Gabriele
D’Angelo, and which I’m going to present at the forthcoming ACM
SAC conference. The paper is titled Content
Cloaking: Preserving Privacy with Google Docs and other Web
Applications and poses (again) a rather simple
question: why should you trust Google to faithfully store your
Google Docs
data? What if roles in the recent Google-vs-China issue
were inverted?

The proposed solution (Content Cloaking) then simply implements
transparent encryption and decryption in the
payload which is sent back and forth between your browser and the
Docs backend. Trying to access your Docs data without a decryption
layer and the needed key will then just show garbage, for both
humans and Google harvesters. Of course you lose something, like
full text search which is performed server-side by Google, but at
least you’re back in charge again: it is you who decides to which
extent trading-off your privacy with offered services.

A proof-of-concept implementation is provided
(and of course is free software!) as an extension for the Firefox
browser, but is now out of date wrt Firefox mainline and was not
really production ready anyhow (let’s say it was
master-thesis-implementation-quality …). Still we, the authors,
stand behind the idea even if we don’t have the energy to maintain
a production-quality implementation.

So, Dear LazyWeb, If you are interested in the
topic and you’ve development cycles to spare, please drop me a mail and I’ll be happy to
point you to all needed details to resurrect the implementation (or
create one from scratch, which should be pretty easy and quick if
you’re familiar with extension development).