Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Password Manager Design Options

Revision as of 17:54, 23 March 2009 by Ptrevithick.gmail.com (Talk | contribs) (New page: {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} right == Proxy or App Design options == There are two options: ;proxy: The password man...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

{{#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).

So far, we're leaning towards "App" above.

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 in a separate (dynamically synthesized) claim type URI in EITHER of the two above options.

Back to the top