Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Architecture

Revision as of 00:20, 16 September 2006 by Paul.socialphysics.org (Talk | contribs) (Components)

This page describes the core components of the planned 1.0 Higgins architecture.

Higgins Consumers

Client apps and services that use these core components are expected to include:

  • Higgins Browser Extension
  • "Relying Party" websites that will consume identity data provided by Higgins-based services. These would use at least the "RP Enablement" component mentioned below
  • Enterprise apps that could potentially rely on the Higgins I-Card Selector service and/or UI, and/or the Identity Attribute Service

Components

Note: In this diagram "PI" means a plug-in. Higgins-v25.JPG

  1. RP Enablement Our intent is to work with identity system vendors to define a standardized interoperable definition of the HTML tags read by HBX and/or other policy expressions (e.g. WS-SecurityPolicy) to express the relying site's constraints and conditions. For testing purposes, especially by relying site developers, we will be developing the RP Enablement component. It implements functions related to Digital Identity verification as well as tools to generate RP Policies and provide access to them via web pages, WS-MEX, etc.
  2. I-Card Broker-Manager WebApp. Provides a management interface to the user's i-cards and underlying context data (if any). This app is accessed by pressing a button embedded in the browser's toolbar.
  3. HBX Support Back end service to support non-authentication related web integration approaches and protocols supported by the Higgins Browser Extension.
  4. ISS UI (WebApp variant). In deployments where the Higgins Browser Extension uses a remote ISS service, this webapp provides the I-Card Selector UI web pages that are displayed by the Higgins Browser Extension allowing the user to select a matching i-card from among those that match the relying party's policy, approve the release of its associated Digital Identity, and allow the user to create their own self-asserted i-cards.
  5. ISS UI (Rich Client variant). In deployments where the Higgins Browser Extension uses a local ISS service, this rich client provides the I-Card Selector UI and the same features mentioned under #5 above.
  6. Identity Selector Service (ISS). ISS negotiates between relying party and identity provider(s) in order for the user to gain access to the services at the relying party. It does this by finding matches between the claims required by policy of the relying party and the claims in available i-cards. As controlled by the policy on these i-cards it uses the ISS UI & HBX Support component to provide a consistent user interface for the selection and release of claims under the supervision of the user. It keeps track of which relying sites and/or services to which the user has released Digital Identities.
  7. I-Card Registry Manages the user's set of i-cards each of which is implemented by an I-Card Provider (plug-in) implementation.
  8. I-Card Provider Some implementation aspects, especially claim mapping, of I-Cards being matched in ISS and presented in the ISS UI components are implemented by I-Card Providers. Some I-Card Providers consume attributes from Digital Subjects in Contexts managed by IdAS, and maps them to the normalized claim "namespace" used by ISS. Other I-Card Providers are facades over remote Identity Providers. I-Card Providers are responsible for importing and exporting I-Cards to Higgins-defined formats as well as formats used by Microsoft CardSpace and other identity systems.
  9. Attribute/Claim Mapping. Used by the I-Card Provider to map attributes (e.g. those from IdAS) into claims that will be transformed and/or digitally signed by a Token Provider.
  10. Token Issuer. The Token Issuer creates relying party Digital Identities from claim data. Claims can either be "pushed" (passed) by the I-Card Provider to the Token Issuer and passed in turn to a Token Provider, or the Token Issuer can "pull" (retreive) claim data from the I-Card Provider.
  11. Token Provider. The Token Issuer relies on Token Provider (plug-ins) for packaging and signing of specific kinds of security tokens.
  12. Identity Attribute Service (IdAS). To support a dynamic environment where sources of identity information may change, it is necessary to provide a common means to access identity and attribute information from across multiple identity repositories. The IdAS virtualizes identity sources and provides a unified view of identity information. IdAS includes services such as: open initial Context, open other Contexts from the initial or other contexts, negotiate/broker authentication during opening of contexts, navigate the contents of an opened context and inspect contained Digital Subjects and their attributes, edit attributes (as allowed by the context's policies), associate of Digital Subjects within and across contexts, creation of new contexts, support management of the attributes of Digital Subjects linked within and across Contexts. The IdAS API will be accessible via Java and other languages as well as via WSDL and HTTP/XML.
  13. Context Provider A Context Provider adds support for one or more kinds of Contexts to the Higgins framework. These Contexts contain Digital Subjects that hold Identity Attributes. A context provider is responsible for its internal data management, security, encryption, persistence, etc. The provider provides the uni- or bi-directional transformation of data from its internal structures to the normalized IdAS data model. In many cases these Context Providers act as adapters or "wrappers" of existing services such as communications systems, collaboration systems, social networks, identity providers, games, enterprise apps, and so on. In addition to web services, Context Providers can also adapt client-side applications such as email clients, IM and other messaging and collaboration apps.. We plan to develop approximately 3-5 Context Providers We expect that third parties may also choose to contribute Context Provider implementations to the project.

See Also

Recent changes to the diagram

  • v24: Changed how "Attribute/Claim Mapping" component interconnects with Token Provider
  • v23: Added a new component, "Attribute/Claim Mapping"; Changed Token Provider to (optionally) pull claim data from I-Card Provider (instead of directly from IdAS, as it had been in v22).
  • v22: Split ISS into two: ISS and I-Card Registry; Renamed DI Provider Framework to Token Issuer; And renamed DI Issuer to Token Provider per discussion at most recent F2F.
  • v21: Removed the "contributed to Higgins" vs. "Higgins component" distinction; Added "optional" interconnect lines; renamed I-Card Broker to "I-Card Manager (Webapp)"; added annotation for I-Card File/Wire Format;
  • v20: Renamed STS to DI Issuer Framework; Renamed Token Provider to DI Issuer; Added local/remote interconnect lines; removed HBX and other requesters (to separate diagram)
  • v18-19: Interface to local STS moved to I-Card Providers (from ISS); Removed "Identity Provider" grey box at the top; Moved Relying Party from the top to its own "Relying Parties" area at the right. Moved lower grey IdP box into its own separate "Service Provider" area. Changed font to Bookman Old Style.
  • v17: Added two new grey boxes: File Import & Export (of I-Cards), Remote IdP; added a line to show that I-Card Broker WebApp will use IdAS API directly
  • v16: Added a line from "Local or Remote Enterprise Apps" to the top of "ISS UI (Rich Client)"; Also, added a new grey box: "Identity Provider (Issuer)"
  • v15: Added "Browser" grey box
Added in missing ISS UI (Rich Client) component --needed to mimic exactly
CardSpace's WinXP-based architecture
Connected the Relying Party to both the Browser and to HBX
Removed End User Components, Developer, Enterprise -> simply added "Enterprise" to :large grey box text instead
Removed the RCP Demo App entirely (retiring it)
Switched the interconnecting lines style
Split ISS UI & HBX Support into two separate components: ISS UI (WebApp) and HBX :Support
Shortened Relying Party Tags & Impl to "Relying Party"
  • v11-14: Added I-Card Providers to ISS; now I-Card Providers consume IdAS API not ISS; add "Enterprise" label
  • v10: Added I-Card Broker Web App to diagram and text
  • v9: Added to IdAS API: Local Language Bindings; added two directional arrows to/from STS; added a "gray" STS
  • v8: Minor formatting tweaks.
  • v7: Split Higgins core into "IdAS" and "Identity Selector Service", removed "root" Context Providers from diagram, added PAM integration, removed all color coding relating to development status, added "3rd party contributed" distinction/color. Higgins has now become just the name of the enclosing projects, but the component names no longer contain "Higgins".
  • v6: Added two JAAS boxes

Back to the top