Talking Identity

I know I’ve been quiet for a while. In large part, I lay the blame at the doorstep of the almighty Twitter. It made it too easy for me to get my thoughts out there without having to put too much effort into it

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 are subscribed to my old feed, and need to switch to the new one. The new feed url is http://feeds.feedburner.com/TalkingIdentity. So go ahead and do that, and you'll be all set to receive my next insightful, witty post. I look forward to using my shiny new toy as I continue talking with you about identity.

Privacy advocates have long been raising a hue and cry about the negative impact social networking sites are having on privacy. For the most part, the glare has been on the poor security practices and privacy controls of these sites. But now researchers at the University of Texas at Austin have brought to light a far more problematic issue.

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".

My previous post on federated provisioning generated some interesting responses, both in the comments and in the blogosphere (see responses from Ian, Pamela and Pat Patterson). The topic has been so engaging (starting with Jackson Shaw's post) that while I was writing this post I saw that Dave Kearns has made it the topic for a series in his newsletter.

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..."

Ian Glazer recently blogged about federated provisioning, saying "Federated provisioning should not exist; there is only provisioning.". Well, I think he's both right and wrong about this. Let me explain.

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?).

Wednesday, January 28 is International Data Privacy Day, honoring the anniversary of the Council of Europe Convention on Data Protection (No. 108), the most important international law for privacy. The purpose of this convention is to secure in the territory of each Party for every individual, whatever his nationality or residence, respect for his rights and fundamental freedoms, and in particular his right to privacy, with regard to automatic processing of personal data relating to him.

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.

One of the online forums I participate in is commonly referred to as the Identity Gang (it is now part of identity commons). An interesting conversation took place last week on the topic of anonymity and privacy. The conversation did branch out a bit (as these conversations often do), but it did bring to the fore some important concepts that need to be clarified.

I found the conversation on anonymity particularly interesting. Those of us in the field of identity management tend to get hung up on terminology a lot. It's an important aspect to any emerging field, as improperly used or appropriated terms tend to create confusion in the marketplace, and act as a barrier to productive engagements. It is with that in mind that I raised the question on the forum last week "Isn't a pseudonym the same as a persona?". Dave Kearns weighed in on my question in this weeks Network World IdM Newsletter.

Much of the conversation last week was on the nature of anonymity and, by extension, pseudonymity. One of the important ideas established is that they are transactional constructs, existing within the context of some identity-based interaction. My question was posed with that frame of reference.

True anonymity in the digital world is pretty hard. There is always some sort of trail (IP addresses, etc) that can lead back to the original user. So it would seem to me that all we have today is varying degrees of anonymity - starting from the barest minimum of information, ranging through being able to piece together a picture based on multiple interactions, having semi-anonymous interactions based on the establishment simply of a username, to a full-fledged fake identity being set up in a website. In other words, all that exists today is pseudonymity.

Does that mean that anonymity is simply an edge case of pseudonymity? I think not. Just because anonymity doesn't exist today does not mean that we don't want to achieve it. Therefore retaining the separation (that an anonymous interaction can never lead back to the originating identity, while a pseudonymous interaction is simply an imposed barrier between the interacting party and the originating identity) is important as a way of enabling us to work towards the technological solutions necessary to achieve anonymity in the digital world.

More interesting is where digital personas fit into this conversation. Look at the definition of a  Persona as defined in the ID Commons Lexicon, and in particular at comment 1:

A Persona is something put forward by a user, but how it is perceived, recognized, accepted, rejected, trusted, used etc. by a Relying Party cannot be specified or in any way implied.

Based on the underlined part, it seems to me that a pseudonymous identity is simply a persona. When a user sets up a persona, they specify the information they want to present through that persona. This information can be completely fake, as minimal as necessary, and set up solely for the purpose of interacting with that one party. In other words, the interaction using that persona is pseudonymous in nature. Since personas and digital pseudonyms seem to share the same characteristic of having a range with respect to amount and transparency of identifying information, it would seem to me that they are one and the same thing.

Understanding these constructs will be important as we move beyond identity management systems and start building persona management systems for use on the web. In particular, understanding the relationship between persona and pseudonymity will help frame the requirements for these systems as they help protect us in our online interactions.

It's been a long time since I have been able to post. A lot conspired to make it difficult for me to keep up with my blogging, not the least of which has been a number of interesting, but under wrap, developments within the IdM group at Oracle (if you follow me on Twitter, you may know what I am talking about). I‘ve been knee-deep in meetings planning our development projects for next year, so stay tuned to this space for a look ahead.

My last post was just before I headed to Prague to participate in a panel on Identity Services at Burton’s Catalyst Europe conference. I could make some jokes about how it has taken me this long to recover from the craziness in Prague, and it would be partly true. But I wouldn’t even begin to know how to describe all of it, so this is me moving swiftly on.

During the panel discussion (thanks to Oracle’s own Dennis MacNeil for taking the photograph above), we talked about the work we’ve been doing in Burton’s Identity Services Working Group (ISWG). Kevin preceded the panel with a presentation outlining the results of the first phase of our work, which has focused on the basic services in an identity services architecture – attributes, authentication and authorization. I can’t really share the results of the work here, because of the rules we work under as part of the working group (I’ll try and talk Kevin into letting me share some of it). However, I will say that one of the interesting developments from the many meetings we had, and which informed the approach taken in this phase of the project, was the group adopting the thought that “Authentication is simply an Obligation in an Authorization process” (think about it). As a result, we have come up with an interesting take on the role of PEPs, PDPs and Claims in the architecture.

The bulk of the panel discussion focused on explaining the drivers for the work being done in the ISWG. The fact that all the folks on the panel were either vendors or financial industry folks meant that the talk was about creating efficiencies, standardizing deployment architectures, maintenance and upgrade headaches and freedom from vendor lock-in. All good reasons to keep in mind when understanding how identity services needs to evolve and get used.

But one of the things that didn’t come up was the fact that our industry as a whole is headed towards a seismic shift in how we deal with identity, and that having a good identity services story is crucial to being able to weather the storm. Change is definitely in the air, and not just because the recent election cycle or recession fears have put that word firmly in our conscious. You can sense this by doing a quick scan of the blogosphere. Rapid advancements in the area of Information Cards and OpenID, Microsoft’s recent work encapsulated in the Geneva announcement, our own work on the IDx project and the emerging talk of the “Open Stack” for identity are all key developments to follow to understand where we are headed as an industry. There is a lot of work still to be done in these initiatives, but one can already see the far-ranging implications of all these projects. And identity services will be the backbone that allows enterprises and applications to adapt in a scalable manner.

Much needed change is on the way, so buckle up.

The last 3 months or so has been really good to my work defining our vision for Identity Services. I've gotten valuable input from my colleagues in the IdM business, and my participation in Project Fusion and Burton's Identity Services Working Group has helped crystallize some key aspects of the architecture. Below is the latest architecture diagram for the Identity Services Platform.

It doesn't look remarkably different from what I have presented previously on this blog, but it do want to point out some of the evolving ideas captured in the diagram above:

• Some of the ongoing discussions that I have blogged about previously have led to a clearer definition of the service called the Identity Hub . In fact, we just put out an Oracle whitepaper talking about the Identity Hub in detail.
• It has become clear that the API Interfaces that the applications rely on to consume these services should be coming from the container that the applications are built on.
• The provider model by which various IdM products plug into the architecture as Service Providers (within the container) is starting to take shape, thanks to good discussion happening in the standards and vendor communities. Consuming applications will not know or care about the specifics of the deployment. This also provides a way for the existing IdM investments to be leveraged (provided we can get all IdM vendors to agree to the requirements of being an Identity Service Provider).
• Authentication and Authorization are both going to have to support contextual and risk-based decisions. This will require greater communication from the applications into the services, and vice-versa.

You can check out a presentation I have put together on how the various IdM products in Oracle Identity Management can be used to create an initial version of this Identity Services Platform. This is an adaptation of my OpenWorld presentation that I will be using in discussions with some customers that are interested in working with us to define their identity services strategy. As always, input and feedback is welcome. And feel free to tell me specific portions that I should talk about in detail in this blog.

Remember, you can find all my published materials (the presentation referenced above, all the Oracle whitepapers on Identity Services, and more) on the downloads page of my blog.

Spreading the Word on Identity Services at Catalyst Europe

My exciting fall season continues as I head to Europe next week. My trip starts with a brief stopover in London for some meetings, after which I head to Prague for the Europe edition of Burton Group's Catalyst Conference. I've been to Prague before (for pleasure, not business), and I absolutely love that city. So that is as good a reason to go as any.

My participation in Catalyst Europe is to continue to spread the gospel of Identity Services. On Thursday, Kevin Kampman will be presenting the results of the work that has been done so far in the ISWG. Following that, I will be on stage as part of a panel discussion involving both customers (TD Bank, BT, Credit Suisse) and vendors (IBM, Novell, Sun and of course Oracle) that are part of the ISWG.

Title: Identity Services Roundtable: Aligning Vendor Strategies with Customer Needs
Date: Thursday, 23 October 2008
Start time: 11:55 am
End time: 12:45 pm
Room: Congress Hall 2

Should be an interesting discussion. We've had some very good workshops in the working group, and we are anxious to put the results out there for people to see and comment on. It is very much a work-in-progress, so lots of feedback is expected. If you are going to be at Catalyst Europe, then please stick around for this roundtable (unfortunately, it is scheduled as the last session in the conference) and participate. And remember to follow me on Twitter for real-time updates on my Europe trip and the proceedings at Catalyst Europe.

A college student was arraigned on Wednesday for allegedly breaking into Gov. Sarah Palin's private e-mail account last month. Political leanings aside, I  read the news article with great interest for the inherent security implications. Reading it, this line jumped out at me:

The F.B.I. said that the younger Mr. Kernell allegedly hacked into the account in mid-September by resetting Gov. Palin’s password.

I obviously don't know the specifics of how the F.B.I. says the password was reset. But for the sake of our discussion, let's assume that the email system relied on a typical challenge response mechanism (currently the norm in most free email systems). The hacker obviously didn't know the password, but was able to reset the password to something of his/her choosing by successfully answering the challenge questions. In the age of Google, how hard is it to find out the the first school, the first car, the mother's maiden name or the pets name of a famous public personality like Sarah Palin?

As Bob Blakely likes to point out, there are no secrets any more therefore any system that relies on secrets is inherently flawed.

In a completely separate conversation, a colleague of mine sent me the following thought:

All the banks and merchants I do business with online have been increasing their level of security, especially with password complexity requirements.  Historically I have limited all my passwords down to 3 based on the type of site so I had no need to write them down.  Now because of all the different password complexity requirements, especially the password history requirement, I can no longer do that.... so I'm now forced to write them down :( 

In some sick way, more security by merchants is now leading to worse security for me, the user.  I'm forced back to the sticky note.

From the Good News/Bad News Department

The bad news in all this is that we seem to be going through a phase where additional mechanisms introduced to secure the systems in a user-friendly manner have actually exacerbated the problem because they rely on flawed assumptions. The above issues are clear illustrations of this. The mechanisms deployed (challenge response, password complexity requirements) would have been fine on their own for the system they are meant to protect. But these solutions did not anticipate how they would be impacted by the reality of their users online environment. The aggregation of multiple such systems for a user actually ends up degrading the effectiveness of these solutions, to the point where they end up becoming liabilities instead.

The good news is that new technologies and solutions are emerging that (hopefully) will address these problems. OpenID and Information Cards aim to rid us of the multiple password problem by promising a world of reduced sign-on built on trust. Identity assurance technologies (like the ones in Oracle's Identity Assurance Partner Alliance) provide safer, more reliable means to verify the interacting parties identity than traditional challenge response mechanisms, thus preventing the kind of attacks described above.

So better days are coming. The real challenge ahead of us is getting all involved parties (consumers, online enterprises, vendors) educated on how these solutions can be used to make our online lives more secure.

One of the big buzzwords this past month or so has been "Identity Assurance". Liberty Alliance made a big push for the Identity Assurance Framework (IAF)at DIDW last month, conducting a number of sessions/workshops introducing it to the masses. Our old friend Frank Villavicencio, who is a co-chair of the IAEG, was a star at the show, even collecting a Liberty Alliance IDDY award. At OpenWorld, Oracle announced the formation of the Oracle Identity Assurance Partner Alliance, an initiative focused on extending our identity and access management offerings with comprehensive and proactive identity fraud prevention solutions from strategic partners (you can read the press release for details).

So what exactly is Identity Assurance? Simplistically, Identity Assurance is the ability to determine, with some level of certainty, that the person (identity) presenting themselves in an identity transaction is who they are claiming to be. The level of certainty one can have about the presented identity is what is referred to as the "Assurance Level". Identity Proofing is another term that is used in this context (and that I have used in the past), though it is more commonly associated with the verification of ones real world identity during the registration process.

So what are these two initiatives, and how are they related?

Identity Assurance Framework - Think TRUSTe for IdPs

The IAF is coming at the Identity Assurance discussion purely from the authentication angle, especially within federation contexts. It is based, in part, on the Electronic Authentication Partnership Trust Framework and the US E-Authentication Federation Credential Assessment Framework, initiatives designed for the sole purpose of enabling interoperability among electronic authentication systems. As such, it attempts to define a trust framework around the quality of claims issued by an IdP based on language, business rules, assessment criteria and certifications. 

The IAF has published a standard set of assurance levels regarding the authentication of the user (Level 1 means low assurance, Level 2 means medium assurance, and so on. As of today, there are only 4 levels of assurance, Level 4 being the highest level). When a digital token is issued, it states the level of assurance at which the user was authenticated - Level 1 through Level 4.

The IAF defines a certification process through which an independent auditor assesses whether the issuers interpretation of Level 1-4 meets a standard assessment criteria established by IAF. So one issuer may have used a RSA SecureID token in combination with Username-Password to issue a Level 2 token, while a second issuer may have used a biometric challenge in addition to a UserID-PIN to issue a Level 2 token. The RP receiving the token from both issuers simply knows that both tokens are Level 2, and doesn't know/need to know what the actual mechanics were, simply that an audit process certified that the mechanism for generating the token meets the criteria laid out by Liberty IAF.

The IAF is NOT defining any technology or standard protocols. In this sense, the IAF is trying to set up something analogous to the way TRUSTe verifies and asserts through their web seal that an eCommerce site is trustworthy.

Oracle Identity Assurance Partner Alliance - Tools of the Assurance Trade

Oracle IAPA aims at extending Oracle’s Identity Management Suite with partner technologies that offer capabilities such as identity proofing, internet geolocation, multi-factor authentication, out-of-band authentication, endpoint security and secure remote access. As such, its charter is pretty broad in combating identity fraud and providing context-aware security, and this encompasses identity assurance.

The solutions in the IAPA can provide the underlying mechanism by which an IdP can support the main tenet in the IAF, wherein an assertion can be trusted (at varying levels of assurance) to really belong to the entity represented. The IAPA steps in as a way for Oracle IAM to leverage technologies that enhance an authentication process with additional "challenges" that up-level the authentication assurance to the appropriate level - whether it be by using a biometric challenge, a voice challenge, a knowledge challenge based on external data aggregators, etc. So Oracle IAM + IAPA is positioned nicely to be the execution/implementation arm of an IdPs IAF compliance efforts.

Looking To Tie Them Together

One thing I will be exploring is the possibility of having the IAPA stack go through the Liberty IAF audit process. Then any customer deploying Oracle Access Management in conjunction with one of our partners would immediately know the IAF assurance levels of the authentication tokens being issued. Conversely, a customer that is targeting being able to issue credentials of certain assurance levels will be able to identify the solutions that will meet their need.