SAFE Authenticator CLI

Apps
1

While the SAFE Browser provides an integrated Authenticator GUI for users to create and manage their SAFE Network accounts and authorised applications, there are many situations where being forced to use a GUI, such as the browser, is less than ideal.

For example, developers working on a desktop SAFE application, either during development, testing, or even the debugging phase, may find it uncomfortable or overkill if all they need is just the app’s credentials to connect to the SAFE Network to test their application logic, and perhaps not the authorisation flow. In these scenarios having a CLI is much more flexible and easy to use as its output could also be chained with other commands, and/or applications can simply execute the CLI and read the result from its stdout instead of having to interface with the SAFE Browser/Authenticator through the system URI protocol (which in turn requires human interaction, mouse clicks, etc.).

So we’re stoked to be sharing our recent early-stage work on an Authenticator CLI. Ultimately this should provide an alternative to the Authenticator that is currently integrated with the SAFE Browser, and to its communication protocol (system URI), allowing to perform the same set of operations but through a command line user interface, or via a web server.

At this stage, we are not providing a release binary, but just the instructions to build the tool from source code and a simple user guide. Please follow the steps we documented in the README file of the safe_authenticator_cli repository to build it and start using it.

Current known issues and limitations

As said above, this small project is in its nascency, and we are trying to get the community engaged in its progress at this early stage. Thus there are some known issues we still have to sort out, but they shouldn’t prevent you from starting to use this tool:

  • It currently builds for Mock network only.
  • SAFE account secret and password are prompted every time the CLI is executed. We are researching on an additional feature to support credentials store (similar to what’s possible with Git and SSH for example).
  • There is no prompt to allow/deny each authorisation request, they are automatically allowed for now.
  • It doesn’t support system URI protocol yet.
  • The PoC authenticator web service can be executed using the --daemon argument, although it still doesn’t run as a proper OS daemon/service but just as a standalone web server app.
  • We are temporarily using a forked branch of the safe_client_libs crates since some enhancements are required in the main SCL repo to properly support this tool. We already started internal discussions around this particular aspect.

Other issues

While it should be borne in mind that this is not intended to be a feature complete CLI at this stage, we’re very much looking for ideas/direction/features and bugs. So all feedback, ideas, criticism, and any issues encountered can be directly reported here. From which we’ll be looking to plan a new milestone of work on the codebase.

However, please feel free to ask for help and/or clarifications in this same thread as well. We’ll be keeping an eye on it for giving support :+1: :bow: :tada:

22 Likes
2

Great work! It will be very useful for server side apps (e.g. drive mounts on a SAFENetwork proxy web server, IoT devices, etc) so it is good to see this lifting off the ground!

5 Likes
3

It’s great to have this and for us to be able to play and feed into development.

At some point it will make sense to move SAFE Drive over to this so, while I’m too busy with Solid stuff to investigate myself, I have a couple of questions…

  • I see it prompts for credentials, but can you specify a file or other non interactive way to provide them, and if not can that be added?
  • will there be an official API for this, or a way to specify that this, rather than the browser be invoked by the API when an app seeks authorisation?

I guess both of those are asking if there’s a way to integrate this with a desktop app so that invoking the app causes authentication to occur in a seemless workflow from the user’s perspective? And could that be configured to either a) automatically prompt for credentials, or b) to read them from a file without further interaction from the user. For the latter I can imagine providing a script that sets up a safe-auth user on the machine which owns and has exclusive access to a credentials file, and that only the Authenticator would have access (by running as that safe-auth user account, ie using setuid on Linux).

6 Likes
4

Not the cleanest solution, but on Linux: expect(1) - Linux man page.
Examples how to use expect: here.

2 Likes
5

We are indeed researching how to support this, we even had that supported by passing them as arguments but that exposes some security concerns as they would be cached in shell’s command history. So we are looking at alternatives like mentioned above.

This is just another type of UI on top of the safe_authenticator library, as an alternative to the GUI we have in the browser. Thus in terms of API, that should be coming from the safe_client_libs API (and potentially its language bindings), we in fact already had some internal discussions in relation to this aspect.
As per this tool, the idea is that it can be integrated with other apps in different forms, including the system URI already used in browser and apps, or chaining this app using its stdin/stdout with other apps, or using the webservice it already exposes (PoC now and we should see which form such interface should have moving forward).

8 Likes
6

this is not intended to be a feature complete CLI at this stage

Understood, but I’m going to ramble about the longer term here despite this caveat.

SAFE account secret and password are prompted every time the CLI is executed. We are researching on an additional feature to support credentials store

I like the way AWS CLI implements credentials.

They offer

  • command line options like --secret --locator
  • environment variables (well utilised by 12-factor apps)
  • home config file in ~/.aws/credentials (good for global settings)
  • specific config file location specified by command line (good for specific profiles)

This gives a range of flexibility in choosing the appropriate amount of security, convenience, version control, environment variability, inheritance and hierarchy.

Usually I feel there’s one right way to do things, but in this case the flexibility of many ways seems quite useful to offer.

Other big topics to consider

  • optional encrypted configs, when and how do they get decrypted?
  • permissions configuration (was mentioned in OP)
  • config invalidation and deletion
  • config backup / restore
  • option for using hardware devices for configs
10 Likes