As the familiar command of *NIX systems, sometimes knowing who you are is no easy task, sometimes using the correct name is not as obvious as it may seem.
When I went to get married it turned out that the Civil Registry did not call me Juan Manuel but José Manuel. Curiously, many people when they meet me tend to confuse my name in that sense. In principle it is a confusion of little importance, it is that type of mistake that people make with a certain frequency, nothing to do with a machine.
On other occasions they are people who have seen my name written but still, perhaps because it is so common, they do not “get it right”.
I may also have to bear some guilt. Depending on who makes the presentation I have one name or another, Juanma or Juan Manuel in almost all areas of work, Manolo in almost all areas of family. Even other names on other occasions.
This “absence” of identity does not occur with machines in general or with Jidoka robots in particular. In the execution of processes, robots, as they imitate humans, often use usernames and passwords to access different systems, and there must be no confusion about who they are at any given moment.
Jidoka robots are able to use the correct username and password
This information can be very sensitive, so the Jidoka platform provides support for storing credentials securely, using different encryption techniques and establishing secure communications.
In addition, Jidoka robots use the correct username and password depending on the specific need. This is vital because it is not uncommon to find that different users have many roles, such as in SAP or Navision systems, and therefore have access to different options, windows, lists, and so on.
Sometimes, it is also necessary to use different users for the same task depending on their use , so if a robot is using a certain user, another robot would use a different user. This can be useful when systems allow a limited number of connections and this concurrency is below the number of robots that we want to use simultaneously, the Jidoka platform controls and manages this case correctly.
The use of different users can also be temporarily limited, for example, it is possible that a certain user can only be used if the robot is running in the morning and used by another user if the robot is running in the afternoon. Again, for these cases Jidoka comes to our help allowing to define different usage policies at the user level from the simplest “always” through “09:00h to 15:00h from Monday to Friday, all day Saturdays, Sundays and holidays” to a fully customized restriction thanks to the API available to developers of Jidoka robots.
Jidoka is able to get corporate repository credentials
Linked to the management of which user should be used is the obtaining and optionally the updating of passwords. In this sense, Jidoka can obtain, and even update, this information directly from the different corporate repositories such as LDAP, RACF, and so on. In this way, the information would not be distributed through different systems. If these corporate repositories do not exist or if you do not want to use them, Jidoka can store the credentials in its own database using different encryption techniques to avoid risking the security of the information.
As you can see, the Jidoka platform helps the construction of robots with solid pillars in the management of credentials.