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 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. Vitaly - 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. Vitaly - 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. Valery - Actually Higgins System Service is set of components that was designed to allow to switch selectors (either higgins or thirdpaty) that conform HSS architecture. This set includes HSS, HSS Launcher and HSS Manager.
  4. The HSS, HSS Launcher and HSS Manager are all shown running within a single process. Is this correct?
    1. Valery - No, this is incorrect. Each of these components runs in a separate process but logically they serve common purpose - allow the user to swith among various selectors installed on the system.
    2. Valery The idea of keeping HSS related components as a separate set of components is based on the assumption that cardspace and azigo/higgins are not the only selectors allowed in this architecture - any thirdpaty who faliliar with HSS API could write their own selector and plug it in HSS.
  5. Is HBX still talking to HSS via a local socket? When merged with ABX will it then use ACE/TAO IPC instead?
  6. Shown above is "JS PDS Client API #1" and "JS PDS Client #2". These are different APIs, correct?
  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?
  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?

Comments:

3. The Higgins System Service is system service (azigo-service process), invokes HSS Launcher process with current logged-in user's rights. It's because a system service can't invoke UI on Vista and higher versions, so we need additional process.

There is no additional HSS Launcher process on OSX, it (OS) has capabilities to run system service (daemon) with current logged in user's rights. So HSS code is sitting inside azigo-service process on Mac.

In Azigo3 we have system service as well to run PDSClient process. Architecturally, it's wrong to have one system service to launch both PDSClient and HSS processes. Need to update diagrams here (http://wiki.eclipse.org/PDS_Client_2.0_Design). HSS application is selector independent, so it can (or maybe must) work with Azigo3 app without integration inside Azigo3.

4. The HSS is dynamic library, so it's not executable, not a different process. It's loaded by HSS Launcher on Windows and azigo-service on OSX. HSS Launcher and HSS Manager are just windows specific apps (we don't have HSS Manager on other platforms) and they are run in different processes, HSS Launcher is invoked by azigo-service and HSS Manager is .cpl file (kind of dynamic library) which is invoked by system console. HSS Manager calls HSS's APIs directly.


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.

Retrieved from "https://wiki.eclipse.org/index.php?title=PDS_Client_2.0&oldid=224843"

Back to the top