[discuss]: refactor components of the example webapp into a new module & release

[mmoayyed]

Background

As indicated here, I am in the process of adding WebAuthN support to Apereo CAS. CAS does already support MFA providers such as YubiKey and FIDO U2F with typical flows that account for device registration and authentication, and I'd like be able to use the library provided here to continue the effort for WebAuthN support.

Progress

Much of the work is already done and is based on the example web application that is available in this repository, which was extremely useful (thank you!). We have started off with v1.6.0 and hope to keep up and/or even contribute to further development of the codebase here by releasing the integration between CAS and WebAuthn and collecting feedback. In doing the work so far, here is what I have had to do:

• Move relevant components of the example web application to a webauthn module in the CAS codebase. Abstractions such as RegistrationStorage, WebAuthnServer, SessionManager, U2fVerifier, etc and more and wired them up appropriately as Spring Beans (CAS at its core is a Spring Boot/Cloud type of application)
• Wired in additional flows for registration and authentication as they related to CAS handling MFA flows in general, much like what it done for YubiKey, etc.
• Moved client-side code over to the CAS webapp to handle webauthn-related matters between CAS and the browser.

All and all, this has been quite instructive and interesting.

Suggestion

My main concern is the components that are copied off of the example web application to CAS. I realize the intention for these might be to just live their life as examples and demonstrations, and one should really start with their version of the same based on available documentation, but I also think they can be quite re-useable and useful to serve as a baseline for implementations and integrations like the one I have. (i.e. I did not want to create yet again another RegistrationStorage) I would rather not maintain a separate copy of such files, keep it in sync, patch it, match and fix differences in code styles, etc. Rather, it would be much more applicable if such components were available in binary form in jar that one could, optionally, use and wire into an application.

So my suggestions are:

• Could we extract the core components of the example webapp out into a separate module?
• Could we, then, release that module as a separate jar along with other modules here for maximum reuse?

This way, applications such as CAS would not be forced to start from scratch (if they don't want to) and could re-use what is already worked out here and build on top of those, specially for things like support for different types of RegistrationStorage components.

If this does make sense, I am happy to start a modest refactoring process to move things into a new module and submit a pull request for review.

Thank you for your time!

[emlun]

Thanks for the suggestions! If you have some concrete implementations we could take a look at those, but I think it'll most likely be out of scope for this library. You're right that everything in the demo application is meant only as examples - the classes you mention are there rather than in the library because they are implementation specific, and the library is intended to be as environment-agnostic as possible.

For example, the precise implementation of WebAuthnServer is likely to differ significantly depending on if you're using plain JAX-RS, Struts or some Spring framework. Some of these will have their own integrated session management, and if not you probably have something anyway, so you probably won't need a new SessionManager at all. How you manage transient state (including the parameter objects for pending ceremonies) is also likely to differ with the environment, as will your RegistrationStorage depending on whether you're using SQL and how your database is structured. Finally, the U2fVerifier is needed only for performing registrations via the superseded U2F API, and should not be needed by most applications - the demo only has it in order to illustrate how the appid extension works.

I suppose there are some common use cases we could reasonably provide default implementations for - but that would open up for adding more and more of them, and we (Yubico) don't have the bandwidth to support that. So for now we prefer to keep the library quite minimal.

All that said - if you do extract some of your components into a reusable library, you're welcome to let us know. Perhaps we can at least link to it as a related project or some such.

[mmoayyed]

Thank you @emlun for your analysis. I certainly understand your viewpoint and concerns specially around maintenance and bandwidth. I'll do what I can to clean things up and remove parts that might be unnecessary.

What would be a good way here to share the link to the project? A PR to the README perhaps?

[emlun]

Thanks! You can post it here and we'll decide what to do with it.