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

This page describes the planned 1.0 component architecture. Note: "PI" means plugin-like component.


Higgins v21.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 Manager/Broker 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. Adapts the generic ISS service to the specifics of the various 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 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.
  8. DI Issuer Framework. (formerly Security Token Service (STS)). The STS creates relying party Digital Identities from claims it retreives from ISS's I-Card Providers.
  9. DI Issuer. The DI Issuer Framework relies on DI Issuers for packaging and signing of specific kinds of security tokens.
  10. Identity Attribute Service (IdAS) (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.
  11. 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.


Recent changes to the diagram above:

  • 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