Hii @tmortagne! I need your advice . I have these questions on my mind:
Should I keep everything, except the
XWikiAuthServiceImpl) inside the
internalsubpackage, as I have seen this done on the
OIDC authenticator, in which case I want to know where should I keep the code for the registration of credentials(New WebAuthn Credentials, Registration Requests, Response, User session) ? as
XWikiAuthServiceImplonly takes care of authentication and not registration.
Currently I have planned this way of building the WebAuthn authenticator: Add code for credentials (for storing credentials) → Add code for registration of new users (Register users based on stored credentials) → Implement endpoints that are involved in a registration request and then take care of the responses, encoding, decoding JSON, etc → Add code for Authentication (details of which I’ll convey after registration functionality is done, as imo better to focus on one thing at a time).
Currently, a user registers themself by providing their First name, Last name, email, username and password. But this will not be the case when the user has the webauthn-authenticator since we are using public-key cryptography and passwordless authentication. In this case, IMHO it will be better to register users first with only a username. One approach is that the users registered via webauthn-authenticator will be completely different users than those registered via default form registration(if that is possible). Another approach is, the webauthn username can be matched with a previously existing username (that was registered using default registration form) and the webauthn-credentials(userID + public key(s)) can be added to their account. So, when they login using webauthn-authenticator, they can access their old account which they had made using the same username from the default form registration. WDYT?
If a user has these 3 credentials: userID, public-key and username. Is it possible that they are considered as any usual xwiki user when I am thinking of implementing registration service for these users? Ofcourse there are other fields too related to these users, but I want to know if the default registration of users can be overridden in some manner or we have to create a new way out?
How should I deal with independent java classes(those who neither
implement)? Should I convert them into interfaces and provide implementation for them inside internal subpackage, and later use this implementation in other components by injecting them? Am I able to understand it correctly? I figured this out after following 1, 2, and 3.
This is regarding endpoints. In
oidc-authenticatoryou have defined an endpoint here and used it only here. In
oidc-provider, you have defined an interface role here and implemented it in 4-5 places(components). I want to know what is your advice for me, since I will be going to work on these endpoints inside a single package, should I create another package or work in this only(webauthn)? I need 2-3 endpoints each to call both for registration as well as authentication.