informatics-isi-edu / webauthn

feature branch for getting GO groups as attributes
Apache License 2.0
2 stars 1 forks source link

Need documnetation #4

Open robes opened 8 years ago

robes commented 8 years ago

We need to have documentation on this. As far as I can tell there are none right now.

karlcz commented 8 years ago

I thought we had some old wiki content on this but I am unable to locate any on the legacy wikis. I think we need to write new user-level documentation and focus on session-based scenarios we intend to support:

  1. Totally standalone local accounts in DB, as used in CI testing scenarios
  2. GOauth integration using the new (beta) services rather than those being deprecated shortly
  3. Google via OpenID Connect scenario if meaningful (lower priority)

For these scenarios we need to document:

  1. The common REST protocol that clients should follow
  2. The specific deployment configuration approach for each scenario
  3. A brief protocol/architecture overview of how these scenarios work
  4. Brief notes on using the webauthn library in an application service

I don't think we should bother documenting the internal webauthn software structure or provider APIs at present. Reading the source is an acceptable barrier to entry for modifying it right now. Similarly, we can leave more esoteric use cases undocumented, e.g. using message authentication w/o stateful session providers.

carlkesselman commented 8 years ago

How different are 2 and 3 now that we can use the Google OAUTH clients without change for Globus Auth?

Carl


Dr. Carl Kesselman Dean’s Professor, Epstein Department of Industrial and Systems Engineering Fellow, Information Sciences Institute Viterbi School of Engineering

Professor, Preventive Medicine Keck School of Medicine

University of Southern California 4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695 Phone: +1 (310) 448-9338 Email: carl@isi.edumailto:carl@isi.edu Web: http://www.isi.edu/~carl

On Feb 2, 2016, at 11:27 AM, karlcz notifications@github.com<mailto:notifications@github.com> wrote:

I thought we had some old wiki content on this but I am unable to locate any on the legacy wikis. I think we need to write new user-level documentation and focus on session-based scenarios we intend to support:

  1. Totally standalone local accounts in DB, as used in CI testing scenarios
  2. GOauth integration using the new (beta) services rather than those being deprecated shortly
  3. Google via OpenID Connect scenario if meaningful (lower priority)

For these scenarios we need to document:

  1. The common REST protocol that clients should follow
  2. The specific deployment configuration approach for each scenario
  3. A brief protocol/architecture overview of how these scenarios work
  4. Brief notes on using the webauthn library in an application service

I don't think we should bother documenting the internal webauthn software structure or provider APIs at present. Reading the source is an acceptable barrier to entry for modifying it right now. Similarly, we can leave more esoteric use cases undocumented, e.g. using message authentication w/o stateful session providers.

— Reply to this email directly or view it on GitHubhttps://github.com/informatics-isi-edu/webauthn/issues/4#issuecomment-178774304.

karlcz commented 8 years ago

A big difference is that there is no attribute aka group provider when using pure OpenID Connect without Globus integration. So, it's a bit of a novelty setup at the moment unless we allow our local attribute provider to compose with remote identity providers.

karlcz commented 8 years ago

@ljpearlman, please review for accuracy and complete the section on session establishment workflow. Then, reassign to @robes to review for scope since he submitted the issue...

karlcz commented 7 years ago

I took a quick look and it seems to me the webauthn documentation is still pretty out of date with our actual code. I'm returning this to the backlog since it's not appropriate to park it in review. (oops, I was off by one, it's actually parked in the "in progress" state)