There’s a little bit of a kerfuffle going on in XACML-land. A non-Gartner analyst made the claim that XACML is dead. Such a claim doesn’t go unnoticed; so Gerry, Anil, Danny, and Remon have all responded that no, XACML isn’t dead. It is not pining for the fjords. It isn’t even zombified.
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.
I saw my first pair of Google Glass at the IAPP’s Privacy Summit a few weeks back. I can’t say for certain but I’ve got a feeling that the wearer was not only loving the utility his pair of Glass provided but also the circumspect looks shot his way by hundreds of privacy professionals. This got me thinking about how societal privacy issues are born – not just with Google Glass but with any technology.
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.
Having deprovisioned your previous Pope, you thought your work was done. But just as soon as you’ve settled back into you desk chair you see it – white smoke wafting up from the chimney. It’s time to provision a new Pope!
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.
Recent announcements got me thinking about how to deprovision executives such as a Pope. Never had to deprovision a Pope before? No worries. We’ve come up with a sure-fire 6 step process guaranteed to help you help your Pope incur a separation from payroll.
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.