Need documnetation

[robes]

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

[karlcz]

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]

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.commailto: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//issues/4#issuecomment-178774304.

[karlcz]

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]

@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]

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)