Anyone can declare a protocol dead. Last year it was SAML. This year, apparently, it’s XACML. Now as someone who killed off the entire IAM industry, I think I’m in a position to comment about this.

It’s easy to say X is dead. SAML, SPML, DSML – doesn’t matter – you declare it dead, write your blog post, and call it a day. But what’s hard to do, and what is necessary to do, is, if you kill something off, you have to offer an alternative. In the case of IAM, I believe we are seeing the hazy outline of what it will become reborn as start to emerge: something more nimble, developer-friendly, and more indistinguishable from business services.  In the case of XAMCL, no alternative was provided.

Just a few things to keep in perspective when thinking about XACML. First, separate externalized authorization management (EAM) from XACML. Enterprises have been doing EAM for decades. The pattern of using something like RACF as a decision-as-a-service facility is a well established practice. Although enterprises may not be using XACML, they are doing EAM and that will only continue.

Second, EAM vendors recognize that they need to increase the number of places where they can provide authorization enforcement. To this end, we see more out-of-the-box PEPs than ever. More importantly, we see EAM vendors team with federation and WAM vendors to offer the rich policy capabilities of XACML paired with traditional, already deployed, enforcement points. That is a huge deal. In fact, my colleague Gregg, predicts that by 2016 80% of fine-grained access control requirements will be met in this manner.

Third, XACML as a system-neutral policy language is an important concept. The ability to translate XACML into local policy languages and thus enable applications that aren’t EAM-aware is key to EAM and XACML’s future. We are seeing this begin to happen in more meaningful ways – such as some vendors’ abilities to translate XACML into SDDL for Windows Dynamic Access Control.

Finally, the standards community has been active too – work on JSON bindings for XACML as well as RESTful bindings will further XACML’s adoption. In addition to this, the OpenAZ project continues to move forward providing a vendor-independent PEP API that anyone can use.

Speaking of standards. Come to Catalyst this year. Hear representatives of the standards themselves why they are relevant and how they can be best put to use doing real work. I’ve arranges a standards smackdown. Come here some industry luminaries represent popular identity standards:

• SAML – represented by Pat Patterson
• OAuth – represented by Paul Madsen
• SCIM – represented by Kelly Grizzle
• XACML – represented by David Brossard
• OpenID Connect – represented by Pam Dingle

Also, I’ll be picking up the ‘Killing IAM’ theme and talking about more about how we as an industry move IAM into the modern era. See you in San Diego.

As Glass debuted, people have been raising multiple privacy concerns including the concern that Glass could send images of people’s faces back to the Googleplex for post-processing such as facial recognition. This concern is rooted in the asymmetric relationship between the people in the line of sight of the Glass wearer, with whom they may not have a relationship, and Google who could collect their image and use it for whatever purpose it sees fit.  The random stranger might not have a relationship with the Glass wearer and she most certainly does not have a relationship with Google (or whoever makes the next Glass-like widget) in this context. The concern, I believe, is not just of asymmetric relationships and power imbalances but also one of post-processing.

Certainly Google isn’t the first organization to gather data for post-processing. From a privacy perspective, news agencies deploy photographers to gather images of people for their form of post-processing – publishing newspapers. Data brokers have gathered both publically and privately available data for post-processing – selling information about one party to another. Our governments gather huge amounts of public and private data, including CCTV images, for their flavor of post-processing as well.

The desire on the part of innovating enterprises is to continue to find ways to post-process information. In fact, this isn’t a desire but a business imperative. And this leaves me with nagging questions:

• How does one opt-out of asymmetric relationships and situations of post-processing?
• Do I have to wear a burqa to keep my face from being swept up by the latest gadget only to be post-processed by a company with whom I have no relationship?
• How do I design privacy-respecting products and services when the end-user isn’t the only party whose privacy I have to be concerned with?

One fictional approach to these problems is found in the devilishly confusing “The Quantum Thief” by Hannu Rajaniemi. In essence, a people living on Mars create a system by which all sensory data is encrypted, before it can be post-processed by the brain. Through different interactions people can grant keys to other people to decrypt this sensory data. You might be aware of a blob walking towards you on the street, but unless I grant you a key, you won’t see my face. You won’t remember our conversation if I don’t grant you another key. And so on.

Ok Earthlings, what’s going to be our approach? Stopping organizations from concocting more and more ways to post-processing information is an impossibility. How then shall we shape our cultural norms? How will our behavior change? How can we smooth out asymmetric relationships and power imbalances?

Before I respond to Michel, it is interesting to note what people did not take issue with. Stateless identity, apparently, isn’t too controversial. I think we can agree that identity needs to be where the developers are and increasingly, especially in the mobile setting, this means in a RESTful world – one in which stateless identity is well suited. Furthermore, people didn’t take too much issue with my assertion that OAuth, SCIM, and OpenID Connect, although by no means perfect, are going to be a major part of the future of IAM.

Another thing people didn’t disagree with was my assertion that identity has to be interwoven into services the business craves. Baking identity into the platform is simply just how all major services providers will proceed. To be fair, there was plenty of comment and disagreement over what the impact will be to smaller identity technology providers. But I think we all agree that the way identity is procured and consumed is still evolving.

So, coming back to Michel’s well written rebuttals, the thing I mentioned that seemed to strike a nerve and cause discord was the point that in order to model and manage relationship hierarchies graphs are needed. Caught up in the response was the implication that graphs (and network databases) are superior to LDAP and SQL.

Let me be crystal clear – I didn’t come to throw stones at SQL or rehash the “should I use a directory or a database” conversation. (I agree with most of Michel’s post regarding the storage of information.) My concerns are over the representation of relationships and identities, not the storage mechanism for those relationships and identities. Given the world of complex relationships we live in, the tools we have today for managing “who can get access to what” are poor. The tools are low fidelity. They rely too heavily on artificial hierarchies.

We need richer semantic representations of relationships and identities accompanied by policy management tools that use that richness. Writing authorization policies requires high fidelity; it requires a means for business analysts to express in their own business terms the rules of the road. I believe that a graph representation of relationships and identities can empower such tools. How that data is stored – I leave to data management professionals.

In closing… To Michel – you’ve got identity virtualization capabilities. How hard is it to build an OpenGraph API on your technology? To Microsoft (and Kim specifically) – we’ve been hearing about the power of graphs and Azure AD has such an API. What are people doing with it? To Oracle, IBM, Axiomatics, Dell, Next Labs, ObjectSecurity, and anyone else I left out – show the industry what your authorization policy management tools can do. Let’s see real relationship modeling and management. Let’s see high fidelity policy tools. Catalyst. July 29^th to August 1. Come show the world what you can do.

Step 1 – Meet the new Pope

First things first, go meet the new Pope. Invariably new Popes arrive with panoply of devices that they want connect to continue to be able to use, and this one is no different. You and your CISO take an inventory of all the gadgets the new Pope wants to use: iPhone, Android tablet, Xbox, Chromebook, etc. With list in hand, you’ll have to start working with your security and device management peers on a strategy to quickly get those devices working with your infrastructure. (If the new Pope doesn’t get his time playing WoW: Mist of Pandaria, he gets a bit grumpy.)

Step 2 – Don’t wait for HR

You can’t leave the Pope just to sit on his mitre and wait for access to business systems. The new Pope has got to be productive minute one of his Popehood. But unfortunately, the new Pope won’t be in the HR feed until the next payroll run, which isn’t for another 12 days. Mussolini might have made the trains run on time but not even he could do anything about HR. To be fair, a new Pope isn’t really a new hire but a strange combination of a transfer and a new persona; needless to say, HR is going to need to take their time. This means you cannot wait for the HRMS to signal the user provisioning system to kick into action. Time for the manual bypass! Hand register the new Pope in the user provisioning system, but be ready for some strangeness when the new Pope does finally show up in the HR feed – misspellings, wrong job codes, and missing data will lead to odd provisioning events.

Step 3 – Monitor the birthrights

Once the new Pope is in the user provisioning system, birthright application provisioning ought to kick off. It did kick off, correct? Good. Ideally you’d have a way to signal that the new Pope is a VIP and that those provisioning requests should be put at the top of the queue for processing. Just like password resets, VIP provisioning should get priority through the workflow engine. If you don’t have provisioning connectors for all the birthright applications, you’ll have to phone up the user admin team and make sure that they build the new Pope’s accounts immediately.

Step 4 – Assign the “special” role

You did create a few broad enterprise roles when you deployed the user provisioning system? Good. Time to dust of the rarely assigned “special” role. This is the role that will give the new Pope access to special Pope-only resources – such as access to the complete donor registry and Cardinals communication portal. Once you’ve assigned this, don’t forget to call the CIO and CISO and make sure that they approve the role assignment immediately – hopefully via their mobile device. (If that doesn’t work, try sending another white smoke signal.)

Step 5 – Get the solid gold token

While the provisioning system is chugging along, you’ll need to get the new Pope his stronger authentication credentials. This is going to be tough. Papal-experience is key to the new Pope and a cumbersome authentication process isn’t going please the Pontiff. Try an NFC-based hardware token embedded into his staff. You might be able to fit a hardware OTP generator into his ring. Or perhaps an out-of-band OTP to those mobile devices of his. Whatever you choose, be ready with plan B and C. Remember lost devices and difficult user-interfaces are going to be your problem.

Step 6 – Authorize the Authority

Remember how you pulled the old Pope out of approval workflows when you deprovisioned him? Well, now you have to put the new Pope back into those workflows. For highly sensitive systems and segregation of duties violations, people are likely going to need the new Pope’s approval. This probably won’t happen day 1, but it will take you a while to weave the new Pope into the workflow system.

See? That wasn’t so hard. Six easy steps and your new Pope is ready to go. Maybe he’ll be so impressed that he’ll take you for a spin in the Popemobile.

Step 1 – Listen to HR

In order to kick off the deprovisioning process, ensure that the user provisioning system can, in fact, know that someone has left the organization; the most common way to do that is to “listen” to the HR system. Got that set up? Good. Oh wait, did HR actually submit his status change to ‘Abdicated?’ Does the user provisioning system actually know how to process ‘Abdicated’ status codes instead of ‘Terminated?’ Say a Hail Mary and proceed to Step 2

Step 2 – Disassociate said Pope from super-user accounts

Assuming the user provisioning system knows that your Pope is abdicating, the next step is make sure the he doesn’t “own” any god-like, privileged accounts such as root, domain administrator, SYSOPER, etc. You’d hate it if, whilst processing the deprovisioning event, the user provisioning system wipes out a crucial (often really hard to recover) account. Run a report, check to see if your Pope has some privileged accounts, and if he does, reassign ownership to someone else.

Step 3 – Do Not Delete!

The thing is – you don’t actually want to delete your Pope’s accounts when he abdicates. That would be really really bad. Why? Because all of his emails, the animated gifs of cats he collected, and all other work (and non-work) related stuff needs to go into the special archive where Pope-related materials go for later study. To prevent loss of future discoveries such as the Pope’s draft for a vampire ninja manga, make sure the user provisioning system sends ‘suspend’ verbs instead of ‘delete.’

Step 4 – Wait and See

You’ve got two weeks before your Pope abdicates. Now would be a good time to crank up the monitoring – just in case. Your Pope was a beloved leader but, let’s face it, if he walks off the job with the entire donor’s list and sells it to a multi-tiered marketing firm, the outraged donors will be coming after information security.

Step 5 – Untangle workflow

Your Pope was kind enough to give you two weeks notice. This is not only polite but very much needed. You should spend those two weeks identifying where the Pope is a workflow approver and removing him from those workflows. You do not want a new hire’s request for the keys to the kingdom waiting on your Pope’s approval. Don’t forget those segregation of duty violation workflows either. And access certifications. And… well, you’ll be busy in those two short weeks.

Step 6 – Cake. Cards. Credentials.

On the day your Pope leaves, throw him a party. Lots of cake for everyone and make sure the ratio of cake to people is correct. Make sure there are multiple heartfelt cards wishing him well in his new endeavors. Meanwhile, as the user provisioning system is instructing its connectors to suspend (and not delete) his accounts, make sure to tactfully ask for your Pope’s smart cards, hardware OTP tokens, and any other credential materials you issued him. Yes, the user provisioning will sweep up the mess, but it’s just good form to recover those IT assets and the boys and girls in Accounting will thank you later. Oh, and don’t forget the things the provisioning system won’t likely clean up such as access to shared social media accounts. Last minute, sugary cake-induced tweets can be surprising, at best.

So the next time your Pope, CEO, President, or Grand Poohbah moves on to greener pastures, be sure to follow our easy 6 step process for a safe and successful deprovisioning.

Monday 

A Magic 8 Ball in the Sky: Federated, Distributed, and Cloud Externalized Authorization – Agenda Builder

03 December, 2012 (01:45 PM – 02:45 PM)

Externalized authorization has granted enterprise applications rich decision-making ability and ways of controlling who can do what with what kind of data. Although, identity management services have begun their inevitable migration to the cloud, authorization has lagged its peers.

• To what extent is externalized authorization becoming mainstream?
• What are the deployment patterns for externalized authorization with respect to cloud services?
• What are the challenges of federated authorization?

Tuesday

Panel: New-School Identity Protocols Fight for Your Love – Agenda Builder

04 December, 2012 (03:45 PM – 04:45 PM)

I am going to pit representatives for SAML, XACML, SCIM, OAuth, and OpenID Connect against each other. Some real legends in our industry will present why you should care about their standards. The players:

Wednesday

Panel: National Strategy for Trusted Identities in Cyberspace – Agenda Builder

05 December, 2012 (10:00 AM – 11:00 AM)

The goal of the panel is to introduce the works of some of the NSTIC pilot projects. Representatives from AARP, Health and Human Service’s Office of the National Coordinator (ONC), and Broadridge will discuss the nature of their involvement with NSTIC, the expected outcomes, and how the outcomes will impact the market. The audience will then get an opportunity to ask questions.

Closing Keynote: Putting Strategy Into Action – Agenda Builder

05 December, 2012 (11:15 AM – 12:15 PM)

In this informal panel and discussion, Gartner IAM analysts reveal their key take-aways from the conference. Key issues include: What trends have been revealed while talking to attendees? What should attendees do ASAP upon returning to the workplace? How best can attendees leverage their conference experience?

Lastly, I’ve got a few one on one sessions available. Use the Agenda Builder tool and get some of my time.

See you in Vegas! 

You likely know Mary as a keeper of the Identity Commons flame, tireless participant in IIWs, and major contributor to open identity initiatives. Mary joins us from Meristic, a software services company providing strategy and implementation services in “user-centric” identity management and distributed networks. She’s been involved with the Higgins project, FICAM, and NSTIC. I met Mary at the first IIW and am incredibly excited for her to join our family. Mary will be covering federation, WAM, eSSO, authentication, mobility, open identity, and whatever else we can throw at her.

Burton Group, Novell, and Quest customers will know Nick and his long history in identity.  Prior to joining the Burton Group in 2003, Nick was the DirXML Architect and Engineering Manager at Novell.  Nick held various software engineering positions throughout his decade plus career at Novell.  Nick was a Senior Analyst/Senior Consultant with  Burton Group from 2003-2006.  After leavening Burton Group, Nick returned to Novell as CTO of Security and VP of Product Management.  He then joined Quest Corporation where he was most recently the Chief Technology Officer, but he also served as VP and General Manager over the Identity, Security, and Windows Management team. On a personal level, I have always wanted to work with Nick, and Lori and I bolted at the chance to do so.

With Mary and Nick coming aboard, and Heidi having joined us last month, Gartner for Technical Professionals Identity and Privacy Strategies Team is at full strength. I know we’ve been a tad quiet lately, but with a fully staffed team, expect us to be loud in 2013.

P.S.: If you want to meet the team, come to Las Vegas and join us for our IAM Summit in December. 

P.P.S: If you can’t make the IAM Summit, you can catch Heidi at EDUCAUSE next week, me at Defrag the week after, and Mary on a webinar at the end of the month.

Not only is Heidi a Jersey girl who has serious operational privacy chops, she’s a lawyer to boot. You might be thinking “why hire a lawyer on a team of technical professionals?” Heidi’s operational know-how is exactly the kind that our constituents need access to. Talking about privacy (or identity for that matter) in the abstract is fun but not necessarily practical. And as identity management professionals up their game and start to become a larger part of information protection conversations, the kind of guidance Heidi can provide will be incredibly useful.

So, hang tight while we get her provisioned with a blog and all sorts of other fun stuff. Meanwhile you can find Heidi on twitter. Say hi and start following her – awesome awesome stuff to come!

You’re likely asking, “Federation and user provisioning – how is that a glimpse of the future?” Taken in isolation, you are right; federation and user provisioning aren’t futuristic or anything special to crow about. But the crucial thing to note is that salesforce.com isn’t thinking about identity in isolation, and isn’t deploying identity in isolation. Salesforce.com isn’t offering identity by itself but instead offering identity within the context of PaaS, delivered, managed, and licensed as such. Become a Salesforce customer and you get identity, not as a side dish added in for free, but something baked right into the applications. It is also crucial to note that salesforce.com went well beyond just integrating its own bits, but instead is offering identity services to help integrate and manage non-Salesforce services and identities.

These identity services, with undoubtedly more to come, are woven into not only crucial business applications (like CRM) but into salesforce.com’s PaaS infrastructure. Identity just happens! This is the future of identity services. Identity gets delivered in the context of something the business and IT as a whole cares about.

From a market perspective, this is a huge deal. Cloud-delivered federation and web SSO providers are going to feel salesforce.com’s presence in a major way. New market battlelines are being drawn. The old fight between identity suite vendors will give way to the new fights between salesforce.com, Microsoft Office365 + Azure, and Oracle Public Cloud. This changes the balance of the identity ecosystem and it is too early to tell how smaller identity vendors will fit in this coming world.

I know full well that an announcement does not happily deployed customer make, and salesforce.com will have to prove to the market it can deliver all of this magically identity goodness. But I will give them credit for taking a standards-based approach by not only supporting SAML 1.1 and 2.0 but also OAuth, OpenID Connect, and SCIM. Not only does standards support facilitate identity services, they also will make integrating Salesforce Identity to your identity bridge and on-premise identity infrastructure far easier than if salesforce.com took a proprietary approach. Furthermore, as our upcoming “2013 Planning for Identity and Privacy” will point out, this sort of delivery of identity services can only happen when those services are standards based.

If announcements like this are any indicate, next 18 months are shaping up to be some of the most interesting in the history of identity management.