by Ian Glazer | May 9, 2013 | 7 Comments
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.
[Read more →]
Category: Identity Management Market Tags: #gartnercat, eam, XACML
by Ian Glazer | March 28, 2013 | 1 Comment
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.
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?
Category: Privacy Tags:
by Ian Glazer | March 21, 2013 | 4 Comments
I put my 18 minute ramble/rant on Killing IAM out on the blog a few weeks back, and I have to say, I have been blown away by the response. Besides all the comments on the blog itself, I’ve had multiple people take me aside to discuss some of the implications of killing IAM off so that it can be reborn. And I have to give Michel Prompt at Radiant Logic a special call-out for not one, but two, blog posts in response to what I said.
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.
[Read more →]
Category: IAM Uncategorized Tags: authorization, eam, iag, IAM
by Ian Glazer | March 13, 2013 | 4 Comments
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.
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.
Category: Identity and Access Governance Identity Management Market Provisioning Tags: #pope, Provisioning
by Ian Glazer | February 12, 2013 | 14 Comments
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.
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.
Category: Provisioning Tags: