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

Difference between revisions of "PDS Client 2.0"

(Architecture)
(Architecture)
Line 21: Line 21:
  
 
# ABX is shown above not integrated with HBX, is this correct?  
 
# ABX is shown above not integrated with HBX, is this correct?  
** 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.
+
## 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.
 
# The ACE/TAO Engine is sitting in the middle of the diagram but not within a process boundary. What process does it run in? Does it run in its own process?  
 
# The ACE/TAO Engine is sitting in the middle of the diagram but not within a process boundary. What process does it run in? Does it run in its own process?  
 
## A: The ACE/TAO Code is running inside the other processes. A CORBA server component is embedded in PDS Client. A CORBA client component is wrapped inside IPCClient component which is loaded by ABX and Dashboard. There is no separate process for IPC.
 
## A: The ACE/TAO Code is running inside the other processes. A CORBA server component is embedded in PDS Client. A CORBA client component is wrapped inside IPCClient component which is loaded by ABX and Dashboard. There is no separate process for IPC.

Revision as of 16:35, 25 October 2010

{{#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 Personal Data Store 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.102.png

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. The ACE/TAO Engine is sitting in the middle of the diagram but not within a process boundary. What process does it run in? Does it run in its own process?
    1. A: The ACE/TAO Code is running inside the other processes. A CORBA server component is embedded in PDS Client. A CORBA client component is wrapped inside IPCClient component which is loaded by ABX and Dashboard. There is no separate process for IPC.
  3. What is the purpose of the Higgins System Service?
    1. A: Higgins System Service is set of components that were designed to allow to switch between selectors (either higgins or thirdpaty) that conform HSS architecture. This set includes HSS, HSS Launcher and HSS Manager. Since there is not yet support for IMI in A3, HSS is also not yet in A3.
  4. The HSS, HSS Launcher and HSS Manager are all shown running within a single process. Is this correct?
    1. A: HSS (Higgins Selector Selector) architecture has 3 processes:
      1. HSS Launcher - it is a system service that is responsible for running/restarting if necessary HSS process in each user session
      2. HSS Process - serves token requests from HBX and redirects them to the selected selector
      3. HSS Manager - control panel component that can be used to switch between selectors
  5. 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.
  6. Shown above is "JS PDS Client API #1" and "JS PDS Client #2". These are different APIs, correct?
    1. A: They are the same API, implemented thru different browser extensions for each browser.
  7. Shown above is a third API: ACE/TAO PDS Client API #3. Presumably this, functionaly, is a superset of API #1 and #2, correct?
  8. Where is the wiki doc for API #1, API #2 and API #3?
    1. A: Currently the PAUL API is implemented and accessible thru the ABXs.
  9. As shown there is only one "UI Process" within which PDS Dashboard UI, an embedded browser, an app ("JS from an app-card") inside the browser, and "Dashboard Core" code, etc. all run as subcomponents within this single UI process. Is this correct? Does each "JS from an app-card" run within its own browser thread? Does the Embedded Browser run in its own process?
    1. A: The embedded browser runs within the Dashboard process.


Earlier Architecture

Original Architecture

The PDS Client 2.0 package is shown in light blue:

Active client 2.0.102.png

It consists of the following C++ components:

APIs

@@@@to be written

Schema Mapping

The PDS Client 2.0 can map attributes to and from a context-specific schema (aka vocabulary, ontology, data model, etc.) into the Persona Data Model 2.0. It is also true that if a custom Context Provider is developed that CP can also do its own mapping. Both cases are shown below:

Pds client 2.0.102.png

In the above diagram, the "app" is a browser extension, but any local app could easily have been shown instead. The concept is the same.

Back to the top