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

Password Manager Design Options

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

Proxy or App Design options

There are two options:

proxy
The password manager acts as a proxy for the "real" RP --thus the domain in the RST is the domain of the site the browser is pointing at
app
The password manager IS the RP --it has its own domain/identity --thus the domain in the RST is the domain of the password manager.

Tradeoffs

App

  • Pro: Security. The selector knows explicitly the identity of the app that it's dealing with, and can explicitly permission this app. This is good because it prevents any old plugin (e.g. a rogue plugin) from being able to request the user's un/pw for any site.
  • Pro: Security. This allows the password manager extension to act as an "SSL" RP (as opposed to a non-SSL RP) and thus receive an encrypted token from the selector

Proxy

  • Con: Security. (See above).

The Password Manager has decided to use the App approach.

Note: The full path of the login form is required to be managed (as a single site/domain may have N>1 un/pw login forms). Since the path portion is stripped from the RST, it must be passed as a separate parameter (e.g. in a separate (dynamically synthesized) claim type URI) in EITHER of the two above options.

Back to the top