Questions regarding my GSoC project - I

[DamianArado]

Hii @tmortagne! I need your advice . I have these questions on my mind:

• Should I keep everything, except the WebAuthnServiceImpl class(which extends XWikiAuthServiceImpl) inside the internal subpackage, 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 XWikiAuthServiceImpl only 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 extend nor 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-authenticator you 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.

[tmortagne]

@DamianArado

Should I keep everything, except the WebAuthnServiceImpl class(which extends XWikiAuthServiceImpl) inside the internal subpackage

Yes. What you put outside an internal package is what you want to expose publicly, APIs you want others to use. I doubt you have this need here.

@DamianArado

where should I keep the code for the registration of credentials(New WebAuthn Credentials, Registration Requests, Response, User session) ?

It should go in the same module but appart from this there is not really any strict rule other that putting all this in some *.internal.* package if it’s not a public API (some most of what you are to work on) but which packages exactly is what feel right to you. I would suggest not putting too many classes in the same exact package and create sub packages under internal for each subject, like org.xwiki.contrib.webauthn.internal.authentication, org.xwiki.contrib.webauthn.internal.registration, etc.

@DamianArado

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

This is really not what we want, IMO.

@DamianArado

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

Yes, that’s the kind of thing I had in mind. I would even say that the priority and the most common use case is being able to reuse an existing standard XWiki user with webauthn. You should also make sure that it’s possible to use the same XWiki users with different browsers.

@DamianArado

How should I deal with independent java classes(those who neither extend nor 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.

Your question is not clear, you seem to be mixing “class” with “component” but anyway the answer for both is that you should only make public what you need to be public (in your case, that’s probably almost nothing). There is generally no point in creating an interface implemented by a single class if the interface is not public. It’s just useless plumbing.

@DamianArado

This is regarding endpoints. In oidc-authenticator you 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.

From XWiki point of view there is only one entry point in the oidc modules which is OIDCResourceReferenceHandler (the one called when the path starts with /oidc/) but then the OIDC modules have their own “sub endpoints” system to make easier to implement a new OIDC endpoints (because a really complete OIDC protocol with all the extensions can have quite a lot of those). Whether or not you need to implement the same kind of system mostly depends on how many endpoints you need to implement, in practice you could also simply have if/else on the element which follow /webauthn/ in the URL.
The reason why there is several modules for OIDC is that they serve different purposes, nothing to do with the implementation of endpoints. Currently, in your case, I don’t really see any reason to have several modules.

[DamianArado]

Thanks a lot @tmortagne . That cleared most of my doubts.

@tmortagne

I doubt you have this need here.

Yes, I don’t think webauthn will be used further.

@tmortagne

I would suggest not putting too many classes in the same exact package and create sub packages under internal for each subject, like org.xwiki.contrib.webauthn.internal.authentication, org.xwiki.contrib.webauthn.internal.registration, etc.

Sure, will do it like this.

@tmortagne

This is really not what we want, IMO.

@tmortagne

Yes, that’s the kind of thing I had in mind. I would even say that the priority and the most common use case is being able to reuse an existing standard XWiki user with webauthn.

Got it, so I am thinking I will have to override the standard XWiki user in some way to add these credentials to it and then use the same credentials to authenticate the users ?

@tmortagne

You should also make sure that it’s possible to use the same XWiki users with different browsers.

For every browser that supports webauthn, we have credentials(a public-private keypair), a standard XWiki user should be able to register credentials and then use them to authenticate themselves. For example, a username XYZ will have different credentials in each of browsers a, b or c but he will see the same XWiki user profile when he authenticates himself using the credentials of either of a, b, or c. It’s a kind of one-to-many relationship, one user has multiple webauthn credentials, (not on a single browser) on different browsers. That’s what can be done IMHO.

@tmortagne

Your question is not clear, you seem to be mixing “class” with “component” but anyway the answer for both is that you should only make public what you need to be public (in your case, that’s probably almost nothing). There is generally no point in creating an interface implemented by a single class if the interface is not public. It’s just useless plumbing.

Got it!

@tmortagne

Whether or not you need to implement the same kind of system mostly depends on how many endpoints you need to implement, in practice you could also simply have if/else on the element which follow /webauthn/ in the URL.

I plan to have endpoints this way: starting entry point with /webauthn/. For registration, I need 2 of them, namely: /webauthn/registration/start and /webauthn/registration/finish. Similarly, for authentication I need 2: /webauthn/assertion/start and /webauthn/assertion/finish. Is there any advice you have for me, that I can look into and take care of?

@tmortagne

The reason why there is several modules for OIDC is that they serve different purposes, nothing to do with the implementation of endpoints. Currently, in your case, I don’t really see any reason to have several modules.

Okay!

[tmortagne]

@DamianArado

Got it, so I am thinking I will have to override the standard XWiki user in some way to add these credentials to it and then use the same credentials to authenticate the users ?

If you look at the OIDC authenticator, you will notice that it define its own XWiki class and add dedicated objects to user profiles.

@DamianArado

It’s a kind of one-to-many relationship, one user has multiple webauthn credentials

Yes, and you will automatically have this using XWiki objects in the user profile, see above.

@DamianArado

Is there any advice you have for me, that I can look into and take care of?

Start by looking at what you get as input of your webauthn ResourceReferenceHandler as I mentioned in my previous message before asking how you should do it See also https://extensions.xwiki.org/xwiki/bin/view/Extension/Resource%20API for more details about how resource reference handlers works (but again the easiest is most probably to look at how OIDC does it since you have a very similar need).

[DamianArado]

Quite helpful, thanks so much!