User login via API?

Are we expecting that some future API will allow user login?

1 Like

No, but yes. No in the sense of the exact wording of ā€œuser loginā€: we donā€™t want the user to give their actual credentials to any app (other than the launcher) under any circumstances. However, we also acknowledged that our current mechanism doesnā€™t fly on mobile or headless devices (like servers or embedded) and are heavily discussing alternatives. And so, in that sense: yes, we will be providing mechanisms for apps to gain access to the network more directly.

1 Like

So, no bot users?..

Whatā€™s the different between a ā€œbotā€ and an app with access to the network?

(especially if said app would have access the network through a dedicated account created only for that app?)

1 Like

Login would be initiated by robot rather than necessarily by a human.
Itā€™s just a boundary case, that I wonder is worth considering.

That could also be used for sensors, meters, plcā€™s or rtuā€™s (also think M2M and IoT) to put their data into the Safe Network, that then would work as a PaaS solution?
One could make e.g. a hmi to visualise this data.

So we could e.g. get a more secure ā€˜Scadaā€™ system?
But sending commands to a rtu and plc, via the Safe network, is probably not that straightforward nor the best solution?
Maybe that will be not be quick or reliable (realtime) enough? Extra ā€˜Safeā€™ network step + polling by the rtu or plcā€™s for commands to execute, instead of receiving the command directly.

2 Likes

Most of the time with scada and plc work timing is really pretty important. Iā€™m not sure that taking commands / putting the actual commands on safe would be the best application. I do think that it could be very useful for fault intolerant applications to have the code on safe in immutable form.
Many of the plc systems Iā€™ve set up have a primary and backup. Having them alternate periodically and in the ā€œoff timeā€ checking against the immutable code on safe to make sure nothing has changed could be very beneficial.

If the latency of safe ends up being much less than I currently expect it to be, then maybe you can throw everything I just said out the window though. That would open up a whole new world of opportunities.

Adding to the other part of the conversation though - having IoT devices able to access safe is going to be imperative. There is no other system that I am aware of that can have IoT be secure. Security along with the addition of compute will take IoT to the next level.

3 Likes

I think there are 2 use cases here:

  1. Login to the safe network by either the launcher or directry.

  2. Assuming the application is interfacing via the launcher, authenticating against the launcher itself.

For 2, having permanent auth tokens would be preferable, IMO. They donā€™t expose credentials and permissions can be configured against the token. It would probably be handy to be able to generate these tokens non-intereactively (ie. Prior to run time) too, but it would be easy to create a new launcher app to generate these.

For 1, it isnā€™t so straightforward, as the launcher itself doesnā€™t aquire an auth token on the safe network AFAIK. Instead, it just authorises based on credentials applied at authentication time. Perhaps a mechanism to generate tokens at the network level could be considered, where human login credentials arenā€™t exposed. If these could be managed on the network itself, then any app - launcher or otherwise - could have non-interactive authentication, which could be managed against the account.

Edit: if 2 is feasible, perhaps the launcher could just manage these tokens and just provide a pass through/proxy to authenticate apps directly against these at the network level? This may also help with permissions against network level data structures, as it would be at a lower level.

More simply perhaps, drift away from considering that access is precious and necessarily requires proof of human; consider that some accounts could just be throwaway, with risk relative to the robot using them.

So, while it might not be advisable to have robots logging into human accounts, they could have their own.

Proof of human login, is all about the human interest in their account but robots run with a certain amount of risk anyhow.

This topic was automatically closed after 30 days. New replies are no longer allowed.