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

PDS Client 2.0

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} The PDS Client provides a high level interface for apps that wish to read and write attributes in the Attribute Data Service 2.0. The PDS Client is packaged as either a C++ or Java code library or as a separate operating system process (e.g. on Windows it is a Windows Service).

Functionality

The PDS Client 2.0's main purpose is to provides an API the user's data. It also:

  • Maintains a local copy of some or all of the person’s personal data stored in the remote personal data store
  • Maintains (and syncs to a remote personal data store and from there to other PDS Client instances) the user’s permissions–the decisions that the user has make as to who (what app or relying party) has access to what attributes. For example, the first time a new app/RP asks for a certain set of attributes, the PDS Client will trigger the PDS Dashboard to present the policy decision to the user. The next time this same request happens, the PDS Client remembers the grant and usually doesn’t have to bother the user about it this time.
  • Maintains an OAuth WRAP access token that it gets by authenticating itself to an external authentication service. It passes this token along in XDI messages to the remote PDS service.
  • Can be configured to encrypt attribute values before they are sent over the wire (e.g. in XDI messages) to the remote PDS
  • Contains a local Security Token Service (STS) that allows it to create and sign SAML (for example) tokens for self-asserted attributes.
  • Contains an STS client to support remote IdP/STSes managed by external parties (e.g. to support managed i-cards).
  • Performs cross-context schema mapping.

Architecture

The following diagram highlights (in red) the PDS_Client_2.0, showing it in the context of the rest of the components of the Higgins Active Client 2.0.

Pds client 2.0.104.png

New Questions

  1. Where is the wiki doc for API #1 and API #2?

Answered Questions

  1. ABX is shown above not integrated with HBX, is this correct?
    1. A: Currently, there is no HBX component - the only browser extension is named ABX. In the future, when IMI functionality is integrated. The current ABX, will be renamed HBX 2.0 and it will included merged HBX and ABX functionality in a single BX.
  2. What is the purpose of the Higgins System Service?
    1. A: First of all what we need to answer what HSS is. HSS (Higgins Selector Switch) is set of components that were designed to allow to switch between selectors (either higgins or thirdpaty) that conform HSS architecture.
      1. On Windows platform this set includes Higgins System Service (azigo-service.exe), HSS Core library (higgins-ss.dll), HSS Launcher (ss-runner.exe) and HSS Manager (hss.cpl).
      2. On OSX platform this set includes Higgins System Service (azigo-service) and HSS Core library (higgins-ss.dylib)
    2. A: Higgins System Service is a system service. NT service on Windows and daemon on OSX.
    3. A: Since there is not yet support for IMI in A3, HSS is also not yet in A3.
  3. The HSS, HSS Launcher and HSS Manager are all shown running within a single process. Is this correct?
    1. A: On Windows platform HSS (Higgins Selector Switch) architecture has 3 processes:
      1. Higgins System Service (azigo-service.exe) - it is a system service that is responsible for running/restarting if necessary HSS Launcher process in each user session
      2. HSS Launcher (ss-runner.exe) - serves token requests from HBX and redirects them to the selected selector
      3. HSS Manager (hss.cpl) - control panel UI component that can be used to switch between selectors
      4. Both HSS Launcher and HSS Manager processes use HSS Core library to handle selector switching and token handling.
    2. A: On OSX platform HSS (Higgins Selector Switch) architecture has just one process:
      1. Higgins System Service (azigo-service) - it is a system daemon that use HSS Core library to handle selector switching and token handling.
  4. Is HBX still talking to HSS via a local socket? When merged with ABX will it then use ACE/TAO IPC instead?
    1. A: When HBX functionality is merged back into into new architecture it'll use ACE/TAO based IPC instead of local socket.


Earlier Versions

APIs

Back to the top