Information Technology Reference
In-Depth Information
• Administrators can author declarative policies to control information disclosure
within the scope of each identity federation. Users can also author policies to
control disclosure of user-provided data. In effect, different policies may apply
on the same personal data used for different purposes in the same scope or used
in different identity federations.
• The Identitty Broker has been designed with compliance in mind. An innova-
tive policy issuance mechanism allows associating an administrator's identity
with the digital signature of a policy fragment (or a user's identity with digital
signatures of user-generated data). It also facilitates providing evidence that
policy fulfilment and disclosure of identity data is in compliance with explicitly
defined rules of use.
• This capability has been designed for use within Virtual Organizations (VO).
It is easy to manage in multi-administrative environments and integrates
with related VO capabilities (such as the VO-Set-Up capability described in
section 8.2 of this chapter). For each identity federation context, it represents a
partner-specific viewpoint of the associated Circle-of-Trust in a way that trust
relationships between Identity Brokers respect supply relationships associated
with the domain.
• Finally, it is designed for the in-cloud use - it is equipped with a secure web-
services remote management interface that enables it to be assembled and man-
aged remotely and provides the basis for an instrumentation layer utilized by
collaboration services such as the capabilities described in section 8.2 of this
chapter.
An overview of the architecture of the Identity Broker is shown in figure 8.3. In
order to allow managing sets of dynamically instantiated services as pluggable
modules, the management interface is split into two parts: a set of 'core' manage-
ment methods and a single 'manage' action that dispatches management requests to
dynamically selected modules. The signature of the 'manage' method is parametric
and dynamically composed depending on the management interfaces of the modules
integrated in a given STS instance of this capability. The flexibility of XML and
SOA Web Services technology enables this form of dynamic composition.
Referring to figure 8.3, the core management methods include operations for
creating new federation configurations from given specifications, for temporarily
disabling or enabling them and for inspecting their values and meta-data. A proxy
function forwards aspect-specific management requests to the management module
of the respective provider - i.e. the bundle of process and module implementations
fulfilling an aspect of the STS operation in a given context.
Each federation context has an associated federation selector - a mechanism that
maps a virtual identity (e.g. security token) issuance request or validation message or
a management operation to an STS instance configuration. This can be, for example,
a WS-Trust request for issuing an XML security token, such as a SAML assertion,
in the scope of a given collaboration (OASIS 2007). In a simple case, the federation
selector could contain a unique identifier or a collection of WS-Federation meta-
data (IBM 2006). When clients request an STS to issue tokens or to validate tokens
Search WWH ::




Custom Search