In the original code base, the client only continues the protocol if
the list of trusted facetIDs that it receives from the server contains
its own facetID. Thus, the value of the facetID of the client needs to
be loaded into the list of trusted facetIDs on the server for the
registration protocol to complete successfully. However, there is no
documentation describing that this step is necessary and must be done
by copying the appropriate value of the facetID of the client into the
appropriate part of the code on the server side and rebuilding.
In order to make the application work, we need to add the facetID of
the mobile application (fidouafclient) into the trustedIds list in the
FidoUafResoure.java, which is located in the
UAF\fidouaf\src\main\java\org\ebayopensource\fidouaf\res. In this
pull request, we have done the following. On the client side, we added
the button in the mobile application to provide a way of obtaining the
facetID of the mobile application. On the server side, we created a
configuration file called config.properties. This file is used as a
way for the server to load the facetID of the mobile application into
the list of trustedIds. We also added the function in the
FidoUafResource.java to make the server automatically read the value
of the facetID contained in the config.properties file. This
config.properties file is assumed to be located in the
UAF\fidouaf\target\classes\org\ebayopensource\fidouaf\res.
We note here that there is already a way to whitelist a client's facetID
through the rest interface . However, this solution allows
anyone to whitelist a facetID. In particular, no authentication is required
to do so. Since in general it is a good idea to reduce an attack surface
against a system, it is worthwhile to consider an alternative method that
lets the whitelisting of the client's facetID be performed only once and
only by the person who starts the service. This is the approach we take
here in this pull request.
On the subject of client's facetID verification, we also would like to point
out that it would make more sense for the verification of the client's facetID
(to ensure that it is in fact in the list of facetIDs that the server is willing
to accept) to be performed by the server, rather than by the client as is currently
done in the code. However, in order to limit the scope of proposed changes in this
pull request to address only one specific issue, we do not make changes concerning
this particular issue here.
How was this patch tested?
We tested the patch in a straightforward manner. Specifically, we
obtained the facetID of the mobile application using the button that
we added to the application UI. Then, we set the value of the facetID
of the client in the config.properties file accordingly. (See the file
README for the specific syntax.) Finally, we tested the mobile
application by performing the registration protocol. We verified that
the protocol messages were successfully transmitted between the client
and the server throughout the protocol and that the protocol completed
successfully.
What changes were proposed in this pull request?
In the original code base, the client only continues the protocol if the list of trusted facetIDs that it receives from the server contains its own facetID. Thus, the value of the facetID of the client needs to be loaded into the list of trusted facetIDs on the server for the registration protocol to complete successfully. However, there is no documentation describing that this step is necessary and must be done by copying the appropriate value of the facetID of the client into the appropriate part of the code on the server side and rebuilding.
In order to make the application work, we need to add the facetID of the mobile application (fidouafclient) into the trustedIds list in the FidoUafResoure.java, which is located in the UAF\fidouaf\src\main\java\org\ebayopensource\fidouaf\res. In this pull request, we have done the following. On the client side, we added the button in the mobile application to provide a way of obtaining the facetID of the mobile application. On the server side, we created a configuration file called config.properties. This file is used as a way for the server to load the facetID of the mobile application into the list of trustedIds. We also added the function in the FidoUafResource.java to make the server automatically read the value of the facetID contained in the config.properties file. This config.properties file is assumed to be located in the UAF\fidouaf\target\classes\org\ebayopensource\fidouaf\res.
We note here that there is already a way to whitelist a client's facetID through the rest interface. However, this solution allows
anyone to whitelist a facetID. In particular, no authentication is required
to do so. Since in general it is a good idea to reduce an attack surface
against a system, it is worthwhile to consider an alternative method that
lets the whitelisting of the client's facetID be performed only once and
only by the person who starts the service. This is the approach we take
here in this pull request.
On the subject of client's facetID verification, we also would like to point out that it would make more sense for the verification of the client's facetID (to ensure that it is in fact in the list of facetIDs that the server is willing to accept) to be performed by the server, rather than by the client as is currently done in the code. However, in order to limit the scope of proposed changes in this pull request to address only one specific issue, we do not make changes concerning this particular issue here.
How was this patch tested?
We tested the patch in a straightforward manner. Specifically, we obtained the facetID of the mobile application using the button that we added to the application UI. Then, we set the value of the facetID of the client in the config.properties file accordingly. (See the file README for the specific syntax.) Finally, we tested the mobile application by performing the registration protocol. We verified that the protocol messages were successfully transmitted between the client and the server throughout the protocol and that the protocol completed successfully.