Enterprise Identity Management Architecture Guide
An annotated outline of the guide had been circulated prior to the meeting. This was
reviewed, and issues were discussed - particularly issues relating to the scope of the
guide. Several important issues were resolved, making the scope much clearer.
The guide should help an architect to establish an identity management strategy. It
should not necessarily go into questions of detailed design.
A particularly important issue is whether the guide should deal with identities of
things as well as of people. It was agreed that the scope should include identifiable
entities that are actors in the system. It is thus broader than just identities of people,
but is not so broad as to include the whole of systems management.
Identity management cannot only help enterprises, it can also help individuals to
manage their identities (or, to be more precise, to manage the multiple credentials that
they use for different purposes). While this is an important area, it is outside the scope
of the present guide, which relates to enterprise architecture.
Access is granted to systems and services on the basis of identities. An element of
risk is implicit in this. Policies must be able to require different mechanisms for
different purposes in the light of that risk.
Catalog of Identity Management Product Implementations
An infrastructure for the catalog is being developed, to enable vendors to input
product information, and to enable customer organizations to view that information. The
input and display parts of the infrastructure had originally been developed separately. An
implementation of the display system that was integrated with the input system was
available for review at the meeting. The review resulted in a number of requests for
changes and improvements.
Announcement of the catalog had been waiting on development of the infrastructure. It
was felt that the infrastructure is now sufficiently far advanced for the Work Area to
request vendor input. Plans were made to do this.
Common Core Identity Representations
Organizations need to manage the identities of several kinds of people, including
members or employees, employees of business partners, and employees of customers. There
are many different ways of representing an identity, due to different practices in
different organizations and departments, and adoption by product manufacturers of
different formats. Interoperability between systems requires mappings between the identity
representations: a cumbersome and complex process, generally requiring special products or
custom software. A common standard way of representing identities would improve
operational efficiency, and help compliance with legislation.
Note that this does not mean assigning a unique identifier to each individual
at birth that will remain with him or her forever, and be used in all dealings with other
individuals and organizations. It does not even mean assigning a unique identifier to each
individual within each organization that he or she belongs to or has to do with. And it
does not remove the need for identity federation between organizations. It does
mean reducing the number of identifiers that the organization has for each individual, and
it enables the organization to map each other identifier to a single core identifier and
so drastically reduce the number of identity mappings that it needs to manage.
The meeting discussed the value of the concept of a common core identity
representation. There is at this point no consensus on its value. While a case has been
put forward, many Work Area members are not convinced.
Following the previous meeting in Boston, a draft Business Scenario had been prepared.
This draft describes the requirements for a common core identity representation, but does
not discuss the implementation possibilities.
Core identity representations used in various systems include X.500 Distinguished
Names, UNIX™ user and group IDs, Microsoft™ SIDs, and email (IETF RFC 822)
identities. All have problems. An implementation based on pairs of Universal Unique
Identifiers (UUIDs) had been proposed as a common core representation. The meeting
discussed a range of implementation considerations, and agreed on how they should be added
to the Business Scenario.
Open Source Test Suites for Identity Management Protocol Implementations
The Open Group had solicited interest in participation in open source test suite
projects from its member companies, and also from universities. There had been a small
amount of university interest, and a larger amount of interest from member companies with
particular reference to test suites for SAML implementations. This interest was not yet
sufficient to justify the formal setting up of a project, partly as companies had
expectations that commercial SAML test suite products might appear.
Standards Update
Identity management standardization covers:
- Representation of identity information
- Assurance of identity information
- Packaging and transport of identity information
- Profiling of identity information representations, assurance mechanisms, packaging
mechanisms, and transport mechanisms for specific purposes
(Federation provides assurance of identity to one party through trust relationships
that the party has with other parties.)
A detailed review of X.500, IETF, ISO/IEC JTC1 SC 37, W3C, OASIS, WS-I, WS*, and
Liberty Alliance identity management standards was presented. The review treats each set
of standards in consistent terms, describing:
- The nature of the organization responsible for them
- The scope of that organization
- The kinds of identity management standards that it produces
- The identity management standards that it produces
- The current status of its identity management standards
A concise summary of identity management standardization, based on this approach, was
then presented. Subject to some specific comments and corrections, the review and summary
were favorably received.
