Ian Glazer
Research Director
3 years at Gartner
16 years IT industry
Ian Glazer is a research director on the Identity and Privacy Strategies team. His research includes identity and access governance, access certification, entitlement management, user provisioning and role management. Read Full Bio
by Ian Glazer | April 10, 2012 | 1 Comment
Ok, maybe not. But this year’s Catalyst should definitely be part of your summer plans.
Identity is deeply woven into the fabric of business. Every business, regardless of location and sector, relies on identity management. But that being said, your business peers might not recognize that reliance. In fact, we, as identity professionals, have been so successful in providing “basic” identity services such as automated on-boarding, password sync, SSO, etc that the business tends to forget about us. Until big things hit the business: big things such as mobility initiatives and the drive to cloud services. It is these kinds of external trends and topics that are shaping identity management as an industry and as a profession.
Keeping that in mind, Catalyst is a little different than in past years. We (all of the Gartner for IT Professionals research teams) have created an event that weaves our varied areas of research together around 3 mega-topics:
- Mobility
- IT as a Broker: Clouds and Services
- Information Everywhere
Within each of these mega-topics will contain identity content, as well as content from our security and risk management peers and other GTP research teams. This format gives a wider-perspective on a subject while delivering in-depth technical topics.
To support this new format at Catalyst, we have created an IAM virtual track to help you isolate the presentations most relevant to you. These presentations will address:
- How do I control access to cloud services?
- How is IAM relevant to my mobility initiatives?
- How do I bridge my on-premises IAM infrastructure with cloud identity services?
- How has IAM evolved to support my growing requirements?
You can find this virtual track and more information about Catalyst here.
With that, I’ll see you in San Diego, August 20th to 23rd. Be there.
Category: Identity Management Market Tags: cat12, IAM
by Ian Glazer | February 21, 2012 | 4 Comments
I’ve been thinking about “Addressgate.” Watching the conversations flow. And it was an interchange between Nishant and Eric that finally trigger this post and these questions – who is responsible for the use of an API? Who should the market hold accountable for using a provided-API in a way that provides an unwanted surprise on the part of a user? And to whom should researchers turn when they discover an unwanted surprise, or a bug, or a feature, that unknown to users, spews forth personal data, silently, in the dark, like a pulsar?
The API provider is the obvious choice. They built the API after all and they provide the underlying service. The API provider wants their APIs to be free-ranged, to be able to show off all the amazing things their service can do. They want an API that is fully featured, and the market demands this.
But along with a terms-of-service an API provider issues, it doesn’t publish a code of ethics. There are no stone tablets accompanying that SDK a dev just downloaded. Try as they might an API provider has little leverage over what a developer does with their APIs and services. No matter how walled the garden is, surprise API use will happen, privacy will be impinged.
Can those purveyors of walled gardens do more to alert users that an app is accessing a piece of data? Of course. But at what point does this cease to be useful? I already get alerted when an app wants my location. Soon I’ll get an alert when an app wants some address book data. Eventually the alerts will out number the useful messages, and these alerts will be ignored, and we’ll be back to arguing about whether Apple should take more paternalistic actions to protect users from app developers.
Sad to say, but I think ethically-treating APIs, APIs that can only be used for the benefit of the user and display no unwanted surprises are impossible. Too many conflicting interests are at play. Platform providers can and should do more to inform users about apps accessing their data. App developers have to consider multiple privacy-perspectives when building their apps. But neither of these things may be sufficient.
Category: Privacy Tags: #PDS, API, apple, google, Path, personal data ecosystem
by Ian Glazer | January 10, 2012 | 8 Comments
As a technologist you’ve likely heard about the Stop Online Privacy Act (SOPA) or the Protect-IP Act. The intention of these bills, as described by SOPA, is “[t]o promote prosperity, creativity, entrepreneurship, and innovation by combating the theft of U.S. property, and for other purposes.” It provides a range of resource to tackle “foreign websites” who “engage in, enable or facilitate” copyright or trademark infringement. Amongst SOPA’s so-called “reasonable measures” of dealing with the assertion that a site engages in, enables, or facilitates copyright infringement, is the use of DNS filter. In essence, the site’s hosting provider would be required to modify its DNS records such that entry for supposedly_infringingsite.com does not resolve. Beside the well publicized incompatibility between DNS filtering and DNSSEC, DNS filtering has tangible negative effects on federated identity systems including the National Strategy for Trusted Identities in Cyberspace (NSTIC.)
Consider the imaginary example of the University of Imagistan. The University is renowned for its comparative literature, geology, and biology programs as well as it its study-abroad program. The University recently upgraded a section of its website dedicate to excellent study-abroad program, hoping to attract more students from the US. Also the University recently upgraded its search engine making more content accessible from its website
Meanwhile, a professor from the University of Imagistan has been using the National Institutes of Health’s PubMed to aid his research. There she has bookmarked a variety of articles that she found interesting. One thing to note about how the professor logs in to PubMed. Thanks to NSTIC (well FICAM actually, but same idea in this case), she does not need a separate username and password to access PubMed but instead logs in using her credentials from the University of Imagistan – a federated logon. When she accesses PubMed, PubMed gathers credential information from the University’s IdP service.
Now imagine that the University’s search engine discovered, indexed, and then linked to spam found in a student’s University-hosted blog. This spam advertised both herbal “performance enhancement” pills as well as a torrent for Hollywood’s action movie du jour – ‘The Postman Got Disintermediated”. At this point the University is squarely in SOPA’s sights:
- It is a “foreign website”
- A portion of it, the study-abroad program, is “US-directed”
- It facilitates copyright infringement (bit torrent of the movie) and is a threat to health in safety (possibly counterfeit drugs)
If the University’s hosting provider receives and chooses to act upon a request to take the website down via DNS filtering. Now when the professor attempts to access PubMed she cannot. Why? Because the federation between PubMed and the University has been broken. PubMed will be unable to access the identity provider at the University because PubMed cannot resolve it via DNS. This means that the professor loses access to all of the articles she previously bookmarked; the value of PubMed is diminished in the process. Keep in mind, that the professor has absolutely nothing to do with the supposed copyright infringement; she just wanted to use the services that she used to use via federation.
The National Strategy for Trusted Identities in Cyberspace, at its core, promotes the use of federated identity. It asserts that an identity ecosystem can provide stronger, more trustworthy credentials, while offering people greater control over their privacy. The approach SOPA and Protect-IP poisons this ecosystem – denying access to IdPs in turn denies access to downstream relying parties and service.
Using censorship tools to enforce copyright does more harm than good. The DNS filtering in SOPA and Protect-IP proposes breaks federation, denying service to not just a supposed infringing website. SOPA and Protect-IP prevent people, who use identity services (identity provider, attribute provider, etc) from that accused domain, from using services like PubMed and every other relying party such as Flickr, Google Apps, Salesforce.com, etc.) This, my friends, is the definition of collective punishment.
There are a lot of issues with SOPA and Protect-IP, and the bills have inspired a growing chorus of opposition. If reading the works of Congress is unappealing, check out the Center for Democracy and Technology and/or the Electronic Freedom Foundation; they both have excellent coverage of both bills. TechDirt has compiled resources for contacting your Senator or Representative.
UPDATE – January 13
It appears that someone’s (or maybe everyone’s) voice has been heard. Both Lamar Smith and Patrick Leahy have decided to amend SOPA and Protect-IP respectively to remove the DNS filtering sections. It is heartening that Congress has come to its senses and decided not to employ censorship tools to enforce copyright. The only good that came of this affair is the reminder that our identity systems have dependencies lower down in the stack. We must acknowledge and mitigate threats to those foundational layers, regardless whether such threats are technical or legislative.
Category: IAM Tags: DNSSEC, nstic, PIPA, policy, Protect-IP, SOPA
by Ian Glazer | December 20, 2011 | 1 Comment
Just when you think the IAM market is about to settle down for a long winter’s nap, you are proven wrong, as evidenced by yesterday’s announcement that Quest has acquired BiTKOO. This acquisition adds BiTKOO’s externalized authorization management product –Keystone – to Quest’s stable of IAM technologies. With this latest market movement, there are three things to note.
First, this acquisition is a sign that externalizing authorization is becoming more mainstream. Yes, this isn’t the first time an EAM vendor was acquired (see disastrous acquisition of Securent by Cisco), but this is the first time an EAM company was acquired by a company who really got identity. In order to have made an investment, Quest had to have seen that the EAM market grow and be more easily addressed. I think one of the ways the EAM market will grow and thus EAM be more commonly found in IAM architectures stems from the need to protect assets in SharePoint2010. This is a problem for all organization and not just the traditional EAM buyers – financial services and military and intelligence organizations. Quest has an opportunity to bring externalized authorization to the masses, especially if they target SharePoint and the surrounding problems of data and access governance.
Second, it will be interesting to see what Quest does with the core of BiTKOO’s technology – its XACML-based authorization service. Beyond simply offering Keystone as an authorization service, Quest could do some interesting things by more closely tying the IAG capabilities acquired from Voelker. I’ve written about the value of stronger ties between IAG and EAM tools and I expect the market will see continued progress in 2012.
Third, Quest is assembling a formidable brain trust. Doron Grinstein, BiTKOO’s co-founder and CEO, is a sharp guy, whose ability to explain EAM via Visio is unrivaled. He and his team join Nick, Eckhard, Jackson, and Jonathan. Quest better stock up on dry erase markers and buy more whiteboards – the brainstorming sessions this crew will undoubtedly have in 2012 will be epic.
By the way, I’ve been doing a bit research related to externalized authorization management. You might want to check out my recent report, “Achieving Greater Control Over Authorization.” Also be on the look out for two more reports available early next quarter; one report focuses on combatting policy sprawl and its implications for IAG and EAM tools, and the second report part of our Reference Architecture and focuses on how to select an authorization mechanisms.
Yes, the IAM market never sleeps, but I hope you get a bit of a rest this holiday season. See you in 2012!
Category: Identity Management Market Tags: BitKOO, eam, iag, IAM, Keystone, Quest
by Ian Glazer | September 23, 2011 | 5 Comments
Microsoft announced that it has acquired “certain assets of BHOLD.” Without having received more details from the team at Microsoft, my interpretation is that they acquired the core of BHOLD’s product set – because they are claiming the acquisition will add “in-depth role management, separation of duties, access certification, and authorization management.”
This is a sensible deal for Microsoft. Forefront Identity Manager lacks IAG capabilities and an acquisition strategy makes perfect sense. (Interesting to note that of the big brand vendors, IBM will be the only one to grow-their-own and not acquire someone.) It will be interesting to see if Microsoft folds the BHOLD IAG capabilities directly in to FIM or keeps them aside as a separate product. Given Microsoft’s track record, if they decide to roll BHOLD’s IAG capabilities into a future release of FIM, customers should not expect such a release until 2013.
Let’s return to the quote from Microsoft’s web site again… “in-depth role management, separation of duties, access certification, and authorization management.” Catch that last bit? Authorization management. BHOLD had some interesting ways of behaving like a PDP for SharePoint. In some regard, BHOLD was the first vendor to unify IAG and EAM functionality. It will be very interesting to see those if those authorization capabilities end up being used as a module of or bridge to ADFS v2. Time will tell…
So what’s the lottery aspect of this post? Consider that there were at least four IAG vendors who specifically built their solutions on top of ILM/FIM: Omada, Voelker, and BHOLD. The lottery works like this. If you get acquired by Microsoft (or Quest), you win! If you don’t get acquired, you lose and the risk to your market increases. Voelker was acquired by Quest. BHOLD is now Microsoft. This leaves Omada standing alone. If I were an Omada customer, I’d sit tight watch whether Microsoft rolls the BHOLD capabilities in the core of FIM. If Microsoft does offer BHOLD capabilities within FIM, then vendors like Omada will be at risk. If Microsoft offers BHOLD capabilities as a separate product, then there is less risk to Omada and its customers. Needless to say, the market around Microsoft’s identity offerings is just getting interesting.
UPDATE Sept 23 to remove inaccurate reference to DotNetFactory as a FIM-based product.
Category: Identity Management Market Tags: BHOLD, FIM, iag, IAM, ILM, Microsoft, Omada, Quest, Voelker
