Option 1: OpenID Attribute Exchange

Some view provisioning as being little more than an attribute exchange. So it is natural to consider OpenID Attribute Exchange, which allows the federation service to request additional attributes from the OpenID Provider during the authentication flow. Essentially, when the federation service detects that the user doesn’t have an account, it could validate the claims it received as part of the token, and if it needs additional data, then it could add a request for those to its authentication request.

This can solve the data retrieval challenge, and squarely positions OpenID as a JIT Provisioning protocol. But the componentized architecture we have been assuming does face some other problems that it must solve in the enterprise cloud context. These are not problems with OpenID itself, rather with the overall architecture (again, this disappears when all 3 components are combined into a single service application, which is how OpenID-based RPs are able to do this today).

As discussed previously, when the SP is hosting more than one service, you often find that the attributes needed for provisioning depend on which service the user is trying to get access to. This means that the federation service would need to ask the OP for different attributes depending on which cloud service the user is trying to reach. Since the federation service can no longer just work off a static list of attributes that it should always query for, this adds the need for the federation service to able to ask the provisioning service for the list of attributes it needs, in the context of the specific service being provisioned. While the SchemaRequest operation in SPML could be used here, there needs to be a way to differentiate (in a standard way) the complete schema supported for the target by the provisioning system from that subset needed to create an account.

Another challenge created is for subsequent first interactions of the user with the other services hosted at the same SP. Since the provisioning system already knows the user, it already has some of the attributes it needs, but not all. So when the federation service queries it for which attributes it needs to retrieve, it should reply with just those attributes it doesn’t already have (from provisioning the user to a different service). The SchemaRequest operation cannot handle this scenario currently.

The bigger enterprise challenge is how the work on the OP side can be broken up between the OP (federation service) and the provisioning engine (policy and GRC service).

These are minor challenges to be sure (since you can always just get the full schema and update attributes that have changed to maintain consistency), but ones that become important when the flows are examined for compliance and consistency.

Option 2: SAML Attribute Query

In the last post, I mentioned how SAML (with the SSO Profile) and OpenID are both squarely positioned to handle the majority of the basic JIT Provisioning use cases. Good thing is, the SAML folks have been thinking about the attribute exchange problem as well, and in the spec have defined a mechanism to handle this called the SAML Attribute Query, which takes a different approach from the OpenID solution. The query for attributes in this case can go over what they call a back-channel. This can be leveraged to facilitate an attribute exchange between the Provisioning Services on each side of the federation boundary.

The big advantage of this model is that the front-channel (usually the browser, but could be other environments much harder to manipulate) is not getting overloaded with the data retrieval task. Also, since the two provisioning systems are talking to each other, they are fully aware of what is going on and can enforce standard provisioning policies as well as track and audit the happenings on the other side – major considerations in the enterprise space.

However, this does mean that it isn’t truly on-the-fly, since the SAML spec would require that a trust relationship be defined between the two sides ahead of time. There is actually a lot of interesting work being discussed right now in the SSTC that could directly influence fed-prov use cases, so I would encourage folks to keep an eye on that.

Option 3: OAuth + ArisID (IGF)

Last (but not least) is a possible solution that I first contemplated on my blog a few months ago, and have since been noodling over with other folks, and that is the thought of leveraging two emerging powerhouses – OAuth and the Identity Governance Framework. The idea here is very simple. When the user first goes to the SP, the SP can initiate the creation of an OAuth connection with the enterprise provisioning engine, facilitated by the user, of course (this is, after all, a user-centric protocol). The enterprise, for its part, can put in place policies and risk-based controls that would allow it to trust such a connection. With the connection between the parties established, the SP provisioning service can now use the ArisID APIs being defined as part of the IGF work to retrieve the data it needs. IGF adds a whole policy layer here, since the SP will provide a CARML declaration regarding itself (for instance, including details of its SAS 70 certification), the attributes it needs, and how it intends to use them (emailing user policies, storage policies, etc). The enterprise provisioning engine for its part can evaluate the CARML file and publish it’s own AAPML file with its policies.

One of the interesting things about this approach is that it enables the creation of on-the-fly trust between the two sides. The enterprise may never have dealt with this SP before, but can still interact with it with a certain level of trust. This trust is built on two separate components – the assertion from the user itself asking that provisioning take place (OAuth flow), and the CARML file declarations (IGF flow) – that make the creation of the federation a risk-based decision (automate-able) as opposed to a business decision (manual). Since this model also involves the provisioning engines on both sides, the security and policy controls can be enforced.

Still Work To Be Done

These models obviously need to be explored and poked at in depth to determine if they hold. And while these depend on some standards work that is still to be baked, there is a lot of other standards work happening (in particular in the OpenID and OAuth arenas) that could supplant these options completely.

And there are major lifecycle management issues still to be discussed and explored. How does one handle de-provisioning in a JIT Provisioning environment? How can SPs that want to know about profile updates find out outside of the user interaction? And how do all those workflow and policy based controls that are present in Provisioning systems today fit into all of this? Well, I will be exploring some of this in my Burton Catalyst North America talk on “Beyond SPML: Access Provisioning in a Services World” in July. So be sure to check out that session if you’ll be there. In the meantime, please keep leave your comments and feedback here so we can keep the discussion going.

[Ends Part 4 of 4]

Tags: Attribute Exchange, Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries, Identity Governance Framework, IGF, JIT Provisioning, OAuth, OpenID, SAML

1. What are the strategic advantages of becoming an IdP?
2. As a consumer or RP, how do I know if an IdP is reliable?

I don’t think I can authoritatively answer these, but I do have some thoughts. And keep in mind that these points apply to any IdP-RP based technology, not just OpenID (think of Facebook Connect opening itself up to be an IdP to other applications).

What are the strategic advantages of becoming an IdP?

Well, for one, you get all the marketing buzz associated with doing something with an emerging, potentially game-changing standard. And marketing buzz is always good, especially when you can get it relatively easily (as Johannes points out).

Secondly, being an IdP allows you to hold onto the all-important identity data that is the fuel of any IdP. This is tied to the continuing value associated with “owning the identity silo”. And it gives you a way to even expand that identity database, since you (presumably) have other websites (RPs) redirecting new users wishing to use their services to your sign-up page.

Also, it would appear that becoming an IdP gets you a pass on having to become an RP. The large identity stores to join the foundation board, can all say they did something with OpenID, without having to tackle the difficult and (probably from their point of view) less desirable task of opening their systems up to rely on other parties as RPs.

As a consumer or RP, how do I know if an IdP is reliable?

You don’t. That is probably the chief reason why RP adoption is not taking off. As even Scott Kveton over at the OpenID foundation has said:

OpenID has two challenges it faces to increase adoption and use; security and usability

This isn’t much of an issue now since the RPs that openly support OpenID (pardon the pun) don’t have major security requirements. And the ones that need a little more reliability are going the restricted OpenID Provider route (“log in with your Yahoo ID”).

Without the security thing figured out, its going to be hard to figure out whether an IdP is reliable or not (whether you’re an RP looking for an IdP to rely on, or a consumer looking to sign up for an OpenID somewhere). Hopefully something like the Identity Assurance Framework will emerge as a way to properly advertise the level of security and reliability a particular IdP provides.

In the same post, Scott says:

security and usability will be key drivers to OpenID adoption moving forward

They’ll be more than just drivers. Solving those issues will break the dam that is currently holding widespread adoption back.

Tags: Identity Assurance Framework, OpenID

Now, in his post, Johannes points out the reality of OpenID adoption – that it is a classic chicken-and-egg problem. As he points out, becoming an OpenID Provider is quite easy and relatively harmless (though reliability concerns do enter the picture), and mainly strategic in nature. On the other hand, becoming an OpenID RP has many more considerations and is far more operational, and therefore risky, in nature. By the very necessity of its invention, OpenID has to achieve critical mass in certain classes of IdP before it can be poked and tested to make sure that it is safe and reliable enough to support RPs. The adoption curve for any technology usually follows this kind of path, and so it is with OpenID. Today the RPs are mostly blog commenting systems and simpler, less sensitive services. Tomorrow, you could be using OpenID to authenticate to your online banking account. But there is a lot to be solved and proven along the path from point A to point B.

So if this path is exactly as it should be, what is there to be concerned about? Well, I guess I should have been more explicit in my last post. The thing that worries me is that the thinking seems to be that there is a lot more value in “owning the silo” -  in other words, being an IdP than an RP. So even if the OpenID industry does all the right things, will we ever get to the point where the number of OpenIDs a person has is a manageable number (the true intent of OpenID)? The way that the heavy hitters are rolling out their OpenID Providers leads me to wonder if the “exclusive” arrangements that are starting to pop up in RPs are going to become the norm, forcing users to maintain OpenIDs with a large number of Providers.

Obviously John Q. Public knows little, if anything, about OpenID. So expecting them to understand the message “Log in with your OpenID” on a website is irrational. The solution right now seems to have become websites displaying the message “Log in with your Yahoo ID” (which behind the scenes converts it into the requisite OpenID). This is a neat trick, but creates exclusive IdP-RP relationships that (in some sense) violate the spirit of OpenID. And given that these same heavy hitters now own many of the web properties that I would expect to be RPs (why is FlickR an IdP and not an RP?) makes me wonder if true OpenID adoption is getting pushed out by a few years, effectively postponing the work that needs to be done to make the OpenID system more robust in nature.

Maybe I’m being too pessimistic about all this. But as of today, I have accounts in about 60 different places that I actively use, and only 3 of them are an OpenID RP. I want to move on to the next level, and am wondering what needs to happen to precipitate that.

Tags: OpenID

I wanted to go on a rant, but I see that Adam DuVander over at monkey_bites beat me to it with a much more eloquent one than I could have come up with. I found this part especially priceless:

But Yahoo stopped short — they aren’t letting people use their non-Yahoo (Open)IDs to log in to Yahoo. That’s not OpenID support. That’s essentially Passport 2.0.

Tags: OpenID

Information Cards try to mirror the familiar, real-world experience of presenting cards to prove identity and provide information in the online world, and aims to do so in a safe, secure manner that is resistant to phishing, pharming and MITM attacks. Despite having been put into the wild a few years ago, and despite the tireless efforts of people like Kim Cameron and Pam Dingle to make it accessible, there are scant few web sites (of any note, anyway) that actually allow people to use information cards. The ICF (much like the OpenID foundation, which also kicked into high gear a few months ago) is looking to put some weight behind the effort to evangelize the technology and expand its adoption in the marketplace. As it states on the ICF Web site, the foundations purpose is to

Advance the use of the Information Card metaphor as a key component of an open, interoperable, royalty-free, user-centric identity layer spanning both the enterprise and the Internet.

It will be very interesting to see how the ICF goes about doing this, and when results will start to show. But this is undoubtedly the beginning of something big. For all of us.

Links:

• Press Release announcing the ICF
• New York Times article
• SC Magazine coverage

Tags: Burton Catalyst Conference, BurtonGroupCatalyst08, Information Card Foundation, Information Cards, OpenID, Personal Identity Management, User-Centric Identity

“isn’t this what OpenID aims to do? If not, how not?”

OpenID can be a small (but key) part of the identity services story. The main problem that OpenID tries to solve is one that most people who use the internet extensively face – that of too many usernames and passwords. Instead of having to remember a username/password combo for each website I interact with (Google, Yahoo, Flickr, Magnolia, banking websites, blogs, etc), I can set up and use a single OpenID account at all those websites instead. OpenID also hopes to provide a number of technological advantages to the whole authentication experience by figuring out ways to prevent phishing and pharming attacks.

So OpenID’s main aim is at providing a secure, scalable solution for the authentication service in the identity stack (see below for the latest diagram of the identity services stack, or read our whitepaper on the subject). To a lesser extent, it also hopes to help the identity provider and authorization services by becoming a transport container for identity claims that drive these services.

Identity Services Stack

The vision for identity services has always been that applications should use only those services that they need, and not be forced to use every single service. So simple web applications with minimal needs could get away with simply supporting OpenID. But that should not be confused with not requiring a full-fledged identity services infrastructure where appropriate.

Tags: Identity Services, OpenID

While some worry that the entry of such corporate entities could change the focus of what (till now) has been a community and consumer-oriented project, I weigh that against the fact that OpenID would not be relevant in consumer identity unless these players not only accepted it, but championed it. So I think this is a great thing for OpenID.

I am hoping the next step will be that these services start accepting 3rd party OpenIDs instead of just being providers. I look forward to using my Google OpenID at Yahoo.

Tags: OpenID, Personal Identity Management, User-Centric Identity

Predictions are risky business, especially in the slightly schizophrenic world of IdM. On the one hand, things tend to move way too slowly; on the other hand, things emerge out of nowhere to take center stage. So I tend to shy away from making predictions. But I will talk about what I hope to see happen in the coming year. These are not impractical, fantasy wishes that will require me to find a magic lamp buried in the sand. These are things that have a good chance of happening if we as an industry stay focused.

Integrating Risk Management with Identity Management
Recent events have brought to light the need to build comprehensive integration between risk management and identity management software. Oracle’s acquisition of Bharosa last year was a response to marketplace demand to bring more context into the identity management process. There is a better understanding of the complex heuristics that need to become part of identity management decisions, and how to encapsulate them as workflow and rules. The coming year should bring more tools and more capabilities in these areas.

For the longest time, people would talk about integration in the context of product suites. The focus will now shift to integration in the context of pre-canned and pre-defined solutions and workflows.

Role Management Comes Into Its Own
Over the last couple of years, we have seen Role Management become an established part of identity management. But its real value will be realized when it stops being an explicitly deployed and managed part of IdM (a la access management) looking for consumers, and evolves into a business tool that is deployed within the enterprise context of provisioning, entitlement management and ERP. A number of other folks have already challenged vendors to do this, and hopefully a lot of work going on in this area will come to fruition.

The Evolving Identity Framework
There are a couple of things I hope to see happen this year that will help us move towards our ultimate vision of how identity is used.

• The Identity Services message has been very well received every time I have presented it. In the last year I met a number of individuals, like the folks from the Jericho Forum, the Concordia project, and a number of people at various conferences, who are really committed to changing how Identity becomes part of application development and deployment frameworks. Hopefully the coming year will see some concrete progress made in defining the necessary framework architecture that will enable the externalization of identity from applications
• We have seen everybody and their mother make moves to become OpenID Service Providers, especially the big identity silos. Hopefully this year will see an explosion of services that are OpenID Relying Parties, including some of those same big players. The real adoption of OpenID will come not from the glut of OpenID SP’s, but from the widespread availability of services that accept OpenIDs and do not require registration and username/passwords.
• I also hope to see someone take the Identity Oracle concept and create a viable business out of it. It may not explode right away, but it will start to emerge. It seems obvious that the easiest place for this to happen is in social networking applications like Facebook. They already hold a lot of identity information that they then serve to other applications (those annoying, currently non-critical Facebook apps that clutter everyone’s profile). Putting in place more controls on how my information is shared and with which apps, and then opening the walls to outside applications would be a logical progression in the evolution of identity providers for internet applications. I also hope to see the Identity Governance Framework become part of such a control framework in any Identity Oracle.
  And then hopefully at the start of 2009 I will be commenting on my hopes for the acceptance of internet identity framework tools within the enterprise.

Your Hopes
What are your hopes for the coming year? Leave a comment, or email them to me, so that we can add them to this list. and hopefully take notice.

Tags: Entitlement Management, Facebook, Identity Governance Framework, Identity in Social Networking, Identity Services, IGF, OpenID, Personal Identity Management, Role Management

Isn’t the idea behind OpenID to get to the point where I have one identity for the internet. By my reckoning, in a few years, the number of OpenIDs I have will be in the low 30s, since every service I am signed up for wants to be my OpenID provider. It doesn’t matter if I only choose to use a few of those, the others are still out there, potentially open to abuse. I can configure whether my email service supports POP3 access or not. Shouldn’t I be able to do the same with regards to whether my account is turned into an OpenID?

The Social Graph need Context
Last week, I read with great interest the saga of Scoble’s facebook account. That led to a lot of discussion in the blogosphere about who owns the social graph, and how the social graph should be made part of an open initiative, freed from the silos (Facebook, Plaxo, MySpace, …) in which it is currently “imprisoned”. But there was something about this whole dialogue that unnerved me.

And then Burton’s Bob Blakely brought his usual rational voice to the discussion. The idea of the open social graph bothered me most because by its very nature it ignores the context within which my graph was created. As Bob points out, the relationships were created within the world of a particular application that supplied context and associated controls for those relationships. I have a social graph in LinkedIn and a social graph in Facebook. Do they overlap? For the most part, no. And I don’t want them to overlap either.

The idea that you can take my contact information from Facebook and move it to another application just because we have a relationship in Facebook is a violation of my privacy. It is no different than if people who I gave my business card to in the context of a particular business meeting decided to put all that information into some online application like MySpace. It just feels wrong. Relationship-Centric IdM anyone?

Oracle Hits The Identity and Security Road
And now for some Oracle news. For those interested in finding out more about where we are headed, Oracle is setting out on a 10-city roadshow to discuss key trends in information security, identity management, emerging standards, and technology advancements. Starting at the end of this month, Oracle experts will be joined by leading security analysts Gartner and Burton Group, along with other industry solutions experts. You can find out more about the Information Security Symposium here.

Tags: Identity in Social Networking, OpenID, Social Graph

I mentioned in my last post that the theme to emerge from the first three keynotes was that the nature of identity is about to change. The rest of the conference was a continued emphasis on this idea, and on the topic of identity as a service. And the sessions drawing big crowds were the ones that talked more about emerging identity technologies and architectures.

What of OpenID?
The session ‘Understanding OpenID and the Early Implementations‘ by David Recordon (SixApart) and Eve Maler (Sun) drew a pretty big crowd. Interest in understanding the value of OpenID was high (something the OpenID crowd has not been able to articulate clearly beyond the simple positioning as “SSO for the Web“, leading to some interesting discussions by Bob Blakely, Stefan Brands and David Recordon). Folks were especially interested to hear what Eve had to say, in light of the effort Sun made to issue all employees an OpenID. To be honest, it was a little disappointing. If I remember correctly, she said that uptake has been low. This could partly be because Sun did not create any value for the Sun issued OpenIDs by incorporating it into the work life of a Sun employee. None of Sun’s community sites (like those for open source projects) accept these OpenID’s for authentication, and it cannot be used at Sun partners or service providers either. In fact, it seems like it is mostly a curiosity, evident when she pointed out that the highest usage of these OpenIDs seems to be at a British gambling website. Oh well, it is still early, and hopefully some of the debate in the community will get us further along.

Microsoft makes a Services play
The talk ‘SOA and Identity with BizTalk Services‘ turned out to be a disappointing follow-up to Kim Cameron’s keynote. What I took away from the session was that Microsoft is taking the features they have in BizTalk Server, and rolling out hosted services on top of that. Maybe I am wrong and there is more to it. But with the demoware breaking a couple of times, poor Justin Smith had to resort to a couple of “I think you get the picture” statements to make whatever point he was trying to make.

British Columbia presents the Next Identity Architecture
Ian Bailey, Director of Application Architecture for the Province of British Columbia, gave a very interesting presentation on their undertaking to design an identity management architecture that will deliver what they call “Citizen-Centric Identity Services”. The solution he presented in his talk ‘A Claims Based Architecture for British Columbia‘, was quite interesting to hear. The content of the session has evolved from the presentation he gave previously at another conference, and included much more detail with regards to the identity services needed to make it practical. Their architecture document can be found here and makes for very interesting reading. His session was quite inspiring to me actually, as it gave me an answer (not necessarily the answer) for one of the areas of my presentation that I was having the most trouble with.

Identity Services
That part was the discussion of the API layer needed in any identity services framework. As I pointed out in my talk on ‘Externalizing Identity‘ (you can download the presentation here), the primary purpose of creating identity services is to make it available to application developers so that they can make identity a part of their business logic without having to build the necessary infrastructure. And the API they must code against must be simple enough to use easily, and abstract enough that it has no dependency on the underlying service providing product. Developers cannot code to XML-based standards, and so the idea of a claims-based API seems brilliant in its simplicity. Not sure if it is do-able just yet, but it is worth looking into.

Those familiar with my previous talks and blog posts about identity as a service will note that my architecture for the identity services layer has evolved over time, and has changed quite a bit even from my talk at the Jericho Forum not even a month ago. One of the key changes was the transformation of the “Identity Provider” service into an “Identity Oracle” service. It took a while, but I was finally able to articulate in detail the necessary features of this service that justify renaming it to the term that Bob Blakely (of Burton) introduced at last years Catalyst (or was it 2 years ago?). The feedback I got on the idea of a productized Identity Oracle, and the session in general, was quite interesting and encouraging. So send me your thoughts as well.

For those that are interested, I know that the DIDW folks recorded the audio of the session. I’ll try and make that available here if allowed. If you went to DIDW, you can access it from the post-conference website.

Tags: Application-Centric IdM, Digital ID World, Identity Services, OpenID, Personal Identity Management, User-Centric Identity