Archive for the ‘Market Trends and Analysis’ Category

The Catalyst of Change: What the Winds are Blowing In at the Prague Conference

Wednesday, April 7th, 2010

By Dieter Schuller, VP of Business Development

Everyone is gearing up for the Catalyst Conferences, coming up this month in Prague and later this summer in San Diego. Normally, Catalyst Europe is not on our radar, but we’re looking forward to this year’s conference because Michel Prompt, our Founder and CEO, will be speaking there about how context virtualization will change the way we secure identities and integrate data.

Speaking of change, the Prague conference is centered around the idea of what Burton analyst Bob Blakley calls “the emerging identity architecture.” As he blogged at the beginning of March, “Federation technology, directory virtualization, and contextual access control can be combined to create a technical architecture on top of which this market for identities can emerge.” He finishes with a cliffhanger, promising to: “lay out the roadmap in Prague.”

The changing Identity and Access Management landscape

We’re excited to see Catalyst focus on needed shifts in the Identity and Access Management (IAM) infrastructure. We can’t wait to learn more about what Burton’s proposing, and we’re thrilled to see directory virtualization and contextual access control at the center of this emerging architecture, since that’s what we’re all about.

If you’d like to hear more about how Identity and Context Virtualization is key to an identity infrastructure with the future built in, don’t miss Michel’s session in Prague.

Come join us, we’d love to discuss the future with you!

As we forge ahead into undiscovered territory, we know there will be many new opportunities. After all, change is inevitable, and this year, Catalyst promises to deliver.

If you haven’t signed up yet, use the promo code “INSIDER” during registration, and you’ll get your ticket for only 995 Euros.

And if you can’t make it to Prague, we’ll also be at Catalyst San Diego. Be sure to stop by our hospitality suite!

Earl Perkins: “The Out is Now In”

Wednesday, November 11th, 2009

A Report from Day 1 of the Gartner IAM Summit

I’m attending the Gartner IAM Summit in San Diego this week. It’s always difficult to be inside in a hotel conference facility when the weather outside is 70 degrees and sunny, so the sessions have to be really valuable.

Fortunately, this morning’s keynote from Earl Perkins was particularly good. The session was entitled “The Death of IAM and the Loss of Identity Innocence — A Review of Program Maturity, Services-Driven Change, and New Era Threats.”

Scaling Up to Service-Centric Delivery

According to Earl, “the out is now in,” which means we need to architect and scale the IDM infrastructure not only for employees, but more and more for external constituents.

Earl mentioned that this move to a more service-centric delivery model means that separate architectures for extranet and intranet with IAM are blurring, with extranet-based access, protection, and reporting mechanisms being used to create one consistent, coherent IAM architecture. The scale that IAM is being asked to address is increasingly larger, as well. Where we once spoke of IAM implementations of 5,000, 10,000 and 100,000 users, today, we routinely discuss implementations exceeding one million users. The scale of applications (in type and count) is also increasing.

Bridging the Gap Between Databases and Directories

In fact, one of the key debates that Earl referred to, as enterprises begin to understand the requirements for external constituents, is whether to use a database or a directory. As a vendor of technology that bridges the gap between databases and directory, we’ve been involved in many of these discussions and the conclusion has always been that you need both.

In most enterprises, databases already hold most of the identity data—CRM, orders, billing, and more—that’s required to enable access for external constituents. Databases also provide facilities for transactional integrity and data normalization and are better for updates and reporting. SQL is the preferred protocol for application developers doing CDI (Customer Data Integration) or MDM (Master Data Management).

Directories, on the other hand, provide fast access, more granular security, and enable search without the need to understand the underlying schema. For these reasons, LDAP is the preferred (and often required) protocol for IAM initiatives.

The Convergence of CDI and IAM

These worlds are starting to intersect—and sometimes collide—as CDI/MDM focuses more on improving the partner or customer experience through the web and IAM focuses more on external constituents. In fact, we’re starting to see  the CDI/MDM guys trying to IAM-enable their initiatives, while the identity guys are hard at work making the IAM infrastructure CDI-compatible.

Identity virtualization bridges the gap between these two worlds by enabling you to separate the protocol (LDAP) from the underlying storage, so enterprises can leverage their existing RDBMS investments, which are designed for high-volume storage, and still derive all the speed and security benefits of the directory.

Looking Ahead: The Out is Now Win

The market is finally beginning to understand that the true value of IdM is not in compliance, but in enabling better interaction with the constituents who drive revenue and profits. This is an exciting time to be in this space and an even more exciting time to be working with technology that enables better identity administration and more effective risk management, and also empowers you to develop new initiatives that:

  • Generate revenue
  • Reduce costs
  • Improve the customer experience
  • Drive cross-sell and up-sell opportunities

The IdM and CDI worlds are beginning to converge, as everyone starts to realize that you can’t have one without the other. Identity virtualization provides that bridge…

- Dieter Schuller, VP Sales & Business Development

Manage Globally. Act Locally.

Wednesday, November 4th, 2009


How identity and context virtualization will change the way we manage identities

My company invented the virtual directory to help take the complexity out of IdM. And now we’ve expanded on that idea to deliver a complete integration solution we call “identity and context virtualization.” I’d like to take the opportunity to explain what it is and why we developed it.

First off, when I say “IdM,” I mean it in its largest sense. While governance, risk, and compliance for internal populations is important, the larger and more rewarding task is helping you integrate high-value, heterogeneous identities for externally-focused initiatives, such as WAM, federation, SaaS, and more.

With that in mind, we’ve all got identities to integrate and new architectures to support.

But right now, the elements of identity are scattered across directories, databases, and applications. Reaching across all these heterogeneous, distributed data silos to aggregate and synchronize identities has proven nearly impossible.

So how do we solve today’s integration challenges and lay the groundwork for tomorrow’s modern architectures, such as user-centric identity, Identity-as-a-service, and the cloud? In short, we need to manage globally and act locally. By this I mean that we need to deliver a global view of identity, while we enforce security at the local level, as close to the sources of services as possible.

And this solution needs to be easily deployed and scalable, since nothing’s getting simpler in the world of identity, things are only growing more complex at every level.

But how can we fill such a tall order? Well, we begin with the idea that those who do not understand history are doomed to repeat it.

What won’t work: Wait and see vs. tear it down and start over

Some see the gap between the present and the future and urge caution, saying let’s wait and see what happens. Others want to throw away the current identity infrastructure and build something completely new.

But we can’t wait when it comes to staying productive and maintaining a competitive advantage. And we can’t afford to blow up what’s already there and build an entirely new infrastructure—yet another silo—to take us into the future.

Learning from the past to innovate for the present and future

So we took more pragmatic, evolutionary approach, using what we already have to develop an infrastructure with the future built in. To do that, we revisited an old idea—the metadirectory—and a newer idea—the virtual directory as a proxy—and combined the best of both worlds. The result is a solution that solves the identity integration challenges we’re facing now, while building the right foundation for all those potentially rich future applications, such as user-centric identity, IDaas, and the cloud.

Identity and Context Virtualization: The Best of Both Worlds

Rediscovering what’s old: Metadirectory

From the metadirectory, we learned the importance of building a global reference for each identity, through synchronization, correlation of global/local identifiers, and disambiguation (watch a video about identity and context virtualization). We also found tools that let us build a highly scalable solution.

The metadirectory also taught us what not to do: move every instance, every facet of an identity into a single directory. We cannot simply centralize identity to secure today’s distributed environments or enable tomorrow’s new services. For security’s sake, there are some categories of information that you cannot move around, such as primary credentials—especially passwords, the weakest link in the chain. Plus, when you try to centralize everything, putting all logic and all function in one place, you end up paralyzed by the complexity of the task.

Reinventing what’s new: Virtual directory as proxy

The “virtual directory as proxy,” which is Radiant-speak for what the market calls a “virtual directory,” solved this challenge of centralization by calling the underlying systems to check credentials. This lets security happen in the manner appropriate to each data source—by delegating the security checking, you’re “acting locally”—while providing an abstraction layer to shield applications from the complexity of the underlying silos.

But while we know the virtual directory delegates security quite elegantly, we also know that as a proxy alone, it cannot scale as the number of sources and volume of queries begin to rise.  As a consequence, the “virtual directory as proxy” remains confined to niche tactical deployments for a limited number of identities. And that’s unfortunate because the “delegation pattern” is a key requirement in many of today’s high-volume, heterogeneous, mission-critical identity deployments.

Finally, both architectures taught us that the more complete your abstraction, the better. Basically, metadirectory was not “meta” enough and virtual directory as a proxy was not “virtual” enough. The more comprehensive the model of your system, the more flexibility you have—making your infrastructure more adaptable and protecting it from unavoidable change.

Building a better platform: Identity and context virtualization

The key to delivering identity as a service is the ability to abstract identities with their corresponding security contexts, so you can deliver the best services according to your applications’ needs. The way to achieve that is by linking identity and security context through virtualization. Here’s how we do that:

  • Virtualization simplifies the entire process, acting as an abstraction layer between applications and data sources.
  • Global/local reference and disambiguation delivers one version of the truth by correlating identity overlap and building a global map of your identity. (The “manage globally” side of the equation.)
  • Proxy/delegation passes the credentials and password verification to the original source. (The “act locally” part.)
  • Synchronization provides the scalability, performance, and high availability required when data needs to be moved.

It’s not about the storage, it’s about the service…

This changes how directories are viewed. Now it’s not only about  storage, it’s also about delivering a set of services indispensable for the identity stack—and the directory is enabled to offer those services through the magic of virtualization. But this is more than a point solution that does a quick and dirty remapping of attributes and query routing; it’s a sophisticated virtualization that creates a complete model of your system.

Our approach to virtualization is all about flexibility and scalability. By building a single global data model out of all your existing systems, you have the flexibility to create unlimited new views of your existing data as your applications require. And synchronization between the logical layer and the physical layer is auto-generated, giving you a solution that scales, no matter how complex the integration, high the volumes, or heterogeneous the data sources composing the view.

The most critical element is no longer how identities are stored, but how they’re aggregated, synchronized, and disambiguated—in short, integrating identity first, then delivering it as a directory. This becomes a powerful new way to view directories: as a set of services you could package and deliver, using different protocols as needed—LDAP, of course, but also SQL, as well as newer protocols such as web services.

Delivering a global view of identity…and linking its contexts

Identity virtualization allows you to reach an individual user across all silos to enforce security and deliver other integrated services. But once you have a handle on that identity, you can also begin to look at that user’s interactions across silos—the actor and his context.

But that’s a topic for another post…

We’ll explore the context side of identity and context virtualization next time.

SPF for Your Sun Directory Infrastructure

Tuesday, October 27th, 2009

Add Flexibility and Shield Yourself from Uncertainty with Identity Virtualization

It’s easy to see how losing your company phone service or email would bring your business to a standstill. Now imagine losing your directory infrastructure. While the directory’s value might not be as obvious to the average business user, it’s a mission-critical foundation for controlling access, including authentication and authorization. For many enterprises, the Sun Directory platform is an essential component in their ability to conduct daily business.

I talk with customers every day and we all agree: Oracle’s acquisition of Sun is a game changer—and no one knows how things will shake out. Announced last April, the deal is currently under review by European Union anti-trust authorities, so it will be several quarters before Oracle and Sun are able to discuss the future of Sun’s directory and identity offering. Still, it’s important to understand and address the key challenges we’re all facing right now.

What’s my strategic roadmap for the near and long-term?

Many organizations are currently running Sun Directory 5.2, which has an end of life date of November 2010. Product upgrades are costly, time-consuming, and disruptive. An upgrade to Sun Directory Version 6 would be a major investment, coming at a time when Sun will potentially cease to exist as an independent company and the future of its directory—as well as the overall identity management product roadmap—has yet to be defined. The combined company will end up with two of everything, including two directory platforms. History shows that developing go-forward product plans, as well as integrating products, is a long and uncertain process. And with Sun in the process of lay-offs, there is uncertainty about what level of support will be available in the future.

How will this affect my business relationships and cost structure?

Sun Directory licensing can be quite complex, and all the terms will have to be re-negotiated once Oracle takes over this product. Sun has different license models—annual fee, perpetual license, even a limited use “free” license—and how these will change under new ownership is also up in the air. Companies who license Sun Directory on a per-user basis may also be paying too much, because they have large numbers of inactive users which could be stored outside the directory.

How can I make Sun play well with other infrastructures?

The sale of Sun highlights another identity management issue many enterprises are facing: the difficulty of unifying different directory infrastructures. Along with Sun Directory as a core enterprise identity store, we’ve also seen the rise of Active Directory, which is now a defacto component for most enterprise network and messaging initiatives and the authoritative repository of core identity information for employees. At senior levels within the enterprise, leaders are asking why the identity infrastructure is being complicated by multiple instances of the same data, in some cases maintained by a fragile and complex series of custom-built data and password synchronization processes.

So, given all these questions, how can you protect yourself from the business and technical aspects of unwanted change? Let’s explore how identity and context virtualization can add flexibility to your infrastructure and keep you from getting burned.

Apply Sunscreen: RadiantOne Identity Virtualization

The answer’s pretty simple—and it doesn’t take long to deploy either: Protect yourself with an identity virtualization layer. Sitting between your current Sun Directory infrastructure and the applications that access it, RadiantOne isolates applications from changes to the backend infrastructure. So the application thinks it’s talking to a Sun Directory, while behind the scenes, you have the flexibility to make changes as needed.  This simple yet powerful layer protects you from market dynamics outside your control, and also upgrades your directory and identity infrastructure to meet future requirements, including federation, fine-grained entitlements, SaaS, cloud computing, and multi-tenant services.

Provide flexibility in your infrastructure

Shield your applications from potential changes to your directory infrastructure in the immediate term, and position yourself to create an informed strategy once the new product roadmaps are announced. RadiantOne is a vendor-, product-, and version-agnostic infrastructure that protects your identity investments and enables quick deployment of new initiatives. Whether you decide to upgrade to Sun 6 or change your directory infrastructure instead, a virtual directory buys you time to decide and ensures that applications will feel minimal impact from any changes you make on the backend.

Cut deployment and licensing costs

Directory virtualization allows you to use any directory or data source to store your identity data. Many organizations use RadiantOne to bridge the gaps between the database and directory worlds, enabling the separation of protocol (LDAP) from underlying storage, where RDBMs often makes the most sense. Such a move could significantly cut deployment costs by allowing you to leverage your existing RDBMS investments and still derive all of the directory benefits. Many enterprises have also reduced licensing costs with this strategy by simply moving inactive users into a database, while still allowing applications to access a single directory with both active and inactive users.

Unify your identity infrastructures

Take better advantage of your AD investments: Use RadiantOne to gain a unified view into all your directories—one that’s cost-effective, non-intrusive, and easy to deploy. RadiantOne solves the challenges of authentication and authorization across disparate user directories by remapping certain aspects of your current directory infrastructure back to AD, without impact to existing applications.

RadiantOne: Highly flexible, plays well with everyone

For many enterprises, directory virtualization is a fast, cost-effective solution that provides protection and flexibility for the identity infrastructure—not to mention independence from some of the vendor dynamics discussed above. While this classical use case is still a strong driver, more and more organizations are turning to RadiantOne virtualization to find new ways to consolidate identity information and leverage existing IdM investments for new initiatives.

Identity organizations are enlarging their focus beyond GRC initiatives for internal populations, targeting higher-value externally focused initiatives that deliver new and better services to customers. But these high-volume, highly heterogeneous environments put new demands on your identity infrastructure.

RadiantOne bridges the gaps between the database and directory worlds, separating the protocol (LDAP) from the underlying storage. So customers can leverage their existing RDBMS investments, which are designed for high-volume storage, and still derive all the speed and security benefits of the directory. This makes RadiantOne a strategic infrastructure solution that supports current identity needs and scales up to meet tomorrow’s challenges.

I’d love to discuss how RadiantOne can make a difference to your organization. Send me an email at dschuller@radiantlogic.com, and tell me about your goals and challenges.

- Dieter Schuller, VP Sales & Business Development

The Eternal Sunshine of the Relational Model…

Tuesday, March 31st, 2009

I cannot count the number of times customers or prospects have asked us to remap a relational database structure into a directory, or vice versa. So keeping a separate, different database structure for directories is and has been a very expensive operation for most companies.

So let’s take a look at why we need to have a separate database structure, and how we could reduce the pain of synchronization.

Now, in my previous post, I asked why we need directories in the first place. But I’d like to refine that question a little further:

  1. Do we need a hierarchical structure like a directory? (I’ll be discussing this question in future blog posts, so stay tuned!)
  2. And the issue behind today’s post: do we need a separate, different kind of database to support such a structure? (After all, didn’t we all learn that relational theory is the alpha and the omega, back in Database 101 class?)

Let’s face it, relational databases are:

  • The workhorse of most enterprise applications.
  • Well understood, well supported, and transaction-enabled.
  • Currently optimized for updates.
  • Potentially able to answer to all kind of queries.

So why not implement a directory using a relational model on top of standard SQL engine and avoid the complexity of having to synchronize two very different data models?

Two Possible Directions, Two Big Dilemmas

If we build a directory using relational best practices, we’ll end up with a model that is “standard” and well understood and well integrated with other SQL applications. So far, so good, right? In terms of design, we will likely end up either with a recursive relation, or a static number of joins for a predefined depth of our tree. The problem is that the result of our queries would be atrociously slowno matter how you slice it, multiple joins or recursive queries are very expensive with mainstream SQL implementations. So this approach won’t work because a directory needs fast lookup/queries.

Or we could bypass best practices and build a “hard-coded” hierarchical structure model that just runs on top of a SQL database. In fact, some vendors took this approach (IBM and Oracle, I believe) and it works well.  But the approach is so specific that we’re basically building a hierarchical databasea separate hierarchical structure using SQL as an access method!  This gives us excellent results in term of speed.  But now we’re back to square one: we have 2 different database structures, two different models, and the same old problem of synchronization, This approach buys us speed but creates exactly the impedance headache that our DBA wanted to avoid.

(In fact, If we’re foregoing the relational model, why not just bypass SQL altogether and use the core access method engine (ISAM/B*trees) to win some extra speed, which is how the majority of LDAP implementations have been done?)

The Best of Both Worlds: Caching In…

So on one side we have a highly scalable system that’s optimized for transaction and updates, making it ideal for storing the data from our directory, which could deliver all the queries we need, but not at the right speed, because the multiple joins of a recursive call kills our real time/online performance. But what if we virtualize and cache the result of all queries beforehand, and update this cache incrementally in real time as new entries are created?

That would give us the best of both worlds: the infinite flexibility and scalability of the relational model, and the speed of a directory. On top of that, we also get the rich context that a hierarchical structure, such as a directory, can carry, while benefitting from a well-established, well understood entity relationship model.  So when we write, update, or insert, we’re working in the classic SQL model with transactions our application loves and understands. And when we query, we get the speed of a directory, because the cache is the directory.

One final thing, since all the data from an existing application could now be virtualized as a set of context trees, an interesting thing happens: We inverse the relationship of the directory with the rest of the infrastructure.  The directory no longer sits in splendid isolation; instead, it’s fed by a grass roots effort of “publishing” which could be consumed by the community. (Sounds a little like the web, right?)

But I’m getting ahead of myself here…let’s dive into this in my next post, when I will cover hierarchy, directory, and context.

Oh, and cache, of course. I’m a big fan of persistent cache. ;)

- Michel Prompt, Founder & CEO

From Static Directories to Context Servers

Friday, March 6th, 2009

Bonjour, and welcome to the Radiant Logic blog!

My team and I will use this as a place to share ideas with you on directory virtualization, data services abstraction, and other topics, with a particular emphasis on identity and context. Now, you may have heard me talk about context before. You may have even thought to yourself, “context, context, it’s always context with this guy Michel.”

So what does digital identity have to do with context? And what does context have to do with directory virtualization? Well, if you’ll bear with me for a little detour through the world of directories, I think it will all begin to come into focus.

Directories: Plateau, Legacy…and Renaissance?

After a period of high excitement and fast adoption, directories (by that I mean essentially LDAP directories or their equivalent) have reached a plateau phase. Technically, there’s not much happening and to some extent they’re now legacy. At least, that’s what conventional wisdom would have you believe.

In fact, it’s the issues facing the current directories (and the whole data service layer, really)—things like difficult integrations and lack of flexibility—that have driven the trend toward virtualization. I’d compare it to the evolution of OS virtualization. In the beginning, IBM virtualization on mainframe and then VMware and other virtualization layers, was just about abstracting the low level hardware/devices, so that one legacy operating system would coexist with another. As progress was made, better understanding of this virtualization layer brought about the current craze of server abstraction and the move toward “elastic” and cloud computing.

Linking Identity and Context

I believe that data services virtualization, particularly directory virtualization, will provide another layer of abstraction, a key service that enables a common representation of not only objects, but also their relationships. Not only objects as isolated nouns, but objects forming sentences, organized in relevant context describing the business processes, the myriad of contexts buried in our applications and data silos. The impact in terms of security and identity management would be immediate, but I believe the scope could be a lot larger. It’s about linking identities with the vital context surrounding them.

This is a big topic, and one I’ll be developing here over more posts. I’ll also be considering other questions relevant to the future of identity, security, and data integration, such as:

  • Why do we need directories in the first place?
  • What can we still learn from the directories, or any supposedly “outmoded” hierarchical structure (XML, XML databases, file system, etc…)? Why do we keeping reinventing them!?
  • What is the role of data service virtualization, and why it is a lot larger than the current narrow definition of a virtual directory? Why do we need a context layer, a service that could be a key requirement for an efficient smart, and secure service-oriented architecture?
  • And of course, we’ll have to address the usual suspects: speed, scalability, flexibility, and security.

Thanks for reading, and please feel free to join the conversation.

- Michel Prompt, Founder & CEO