| |
 |
|
by Christopher M. Burry and Ace Swerling, Avanade
Originally published on November 16th. Republished with permission.
NOVEMBER 16, 2004 (COMPUTERWORLD) - It's exciting to anticipate multiplatform
integration with Web services. Federated identity management has made recent
headlines as part of this promise to streamline electronic business. It offers
a taste of what's to come. The very proposition of streamlining processes
depends on reduced complexity. But in most companies, users have too many
accounts, there are too many directories, and nothing interoperates securely.
These issues must be resolved before seamless application integration becomes
practical.
Confusion over how to proceed and the excitement over identity federation have
led people to consider it a panacea to fix identity complexity problems. The
idea has merit, but it's not a complete solution.
Reduce complexity
To create a system like that for driver's licenses, where a single identifier
is recognized and honored everywhere, identities are mapped to each other
across different environments -- whether infrastructure directories,
applications or business processes. Identity federation stipulates that one
identity is equivalent to another so IT doesn't have to reduce the typically
massive number of user accounts.
This can cause problems. As more systems participate, the IT staff has to do
more mapping. Multiple user accounts require still more mapping. When business
conditions change the application environment, even more mapping has to be
done. The resulting complexity increases cost and inhibits business benefit.
The prevailing wisdom over the past decade has been to solve identity
complexity problems using a metadirectory for a measure of account consistency,
plus middleware for security. The metadirectory copies account information to
the various directories within a company. In theory, IT could avoid directory
coordination across the enterprise: Application teams could use their own
directories to speed implementation, and the metadirectory would handle
interoperation.
However, enterprise applications often need custom programming to work with the
middleware layer. The cost and complexity don't always lead to the single,
enterprisewide identity/security infrastructure companies expect.
In the end, identity federation addresses some tactical problems but doesn't
reduce the overall complexity of an environment.
Choose the right instrument
We recommend that our clients consider alternatives to the federation "cure."
Metadirectories and identity federation were created because some situations
are too complex to keep everything in a single directory. But this doesn't mean
that all situations are too complex.
Remember, an integrated, secure environment requires four elements: accounts,
authentication (log-in validation), authorization (rights and permission
validation) and resources.
A single directory where multiple applications can use a single "account"
simply reduces overall complexity. It's a more practical option than most
think, because many of the affected systems fall under a common administrative
authority. These conditions are similar to those in server consolidation.
Where a single directory is impractical, metadirectories, security middleware
and identity federation are perfectly viable. But they must contribute to the
goal of cutting complexity and cost while increasing flexibility and
functionality. Consequently, they're best suited to systems that don't fall
under a common authority and hence are more appropriate for intercompany
scenarios than intracompany ones. They help intracompany scenarios for
short-term migrations but aren't as good in the long run.
With so many tools in the toolbox, it's important to choose the right ones --
based on a thorough understanding of the problem set. The preparatory steps
from our previous column on directory implementation are applicable:
Assess and define architectural goals
Document identity touch points in the organization -- relevant applications and
their identity/security interfaces, and the relationship between applications
and a common directory.
Perform a gap analysis. Assess where systems meet or fail today's business
needs, and identify opportunities for improvement.
Evaluate account provisioning and determine how accounts are initiated, managed
and eliminated. The exercise might be an HR scenario in which a user is hired,
to replicate account creation and update in IT systems, and fired, to map
account termination. With a solid understanding of the situation, it's possible
to work on the solution. Options include combinations of enterprise directory,
metadirectory and identity federation. Identify circumstances that can be
served by a single directory. Where that's impractical, consider alternatives
such as a metadirectory.
Initiate security integration at the infrastructure level to bind security
environments across heterogeneous systems in as streamlined and straightforward
a fashion as possible. Security can then be undertaken at the application
level.
Concurrent with this process, we recommend defining standards for these tasks
to manage impact on employees' work process.
Work in concert
Simplifying identity will lead to a technical architecture that supports
process orchestration. It's analogous to an orchestra, with musicians seated so
that the conductor can lead the performance. The conductor's job would be
impossible if the musicians were arranged haphazardly.
Federated identity management facilitates process orchestration. But
simplification is the key. Though smaller, the chamber ensemble's seating
arrangement is principally the same as the symphonic orchestra's. Set the stage
properly, and federation is an option when it's time to connect with the
outside world.
Christopher Burry is a Fellow and the Technology Infrastructure Practice
Director for Avanade, a technology integrator for Microsoft solutions in the
enterprise. Ace Swerling is an MCSE within Avanade's technology infrastructure
practice.
View the article at the ComputerWorld website.
|
|
|
