I want to add a new authentication mechanic.
When the does a successful login, my code runs and then returns a final login result:
Is this possible?
A solution to this could be if there’s a way to logout a user from the Event Server. Alternatively, purge the user’s active token.
Bump? @Bo Ellegård Andersen (Milestone Systems) @Peter Posselt Vergmann (Milestone Systems)
Sorry about delayed answer, but we are in vacation mode, so we are fewer monitoring the forum than normally.
I am a bit in doubt what you mean logging the user out from the Event Server? The users does not log in to the Event Server.
So are the user logging in to Smart Client or something else? If it is the Smart Client you cannot as such log out a specific Smart Client user from the Event Server as the server does not know about each Smart Client session. What I would suggest would be to make a Smart Client plugin that listens on when the user is logged in and then performs the extra validation. If he is then not authorized show a message and close the Smart Client. This of course requires that you can ensure that the plugin itself is not removed from the client, which can pretty much only be done through the use of Windows security.
In log out the user from the Event Server as in a serverside plugin, is what I meant.
It is possible to create users via plugin, right? A solution could be to create a new application that handles the authentication and if correct, talks to a serverside plugin that creates a temporary user and assign the authorized rights to the user, then returns the information to the app. The app then launch the Smart Client with the supplied parameters. When the user logs out the user-account is removed. Could this work?
You can create (and remove) a user through the Configuration API, so you can do that directly from your application if you want - you don’t need a plugin for that.
But as I understood it, you wanted the user to be verified both against a Milestone account and against something else and I don’t really see how creating a temporary user achieves that.
You’re right, it doesn’t, but I’m just brainstorming. How about the user have a dummy account with no rights to log in with. The application connects to the Milestone system and via messages communicates with a serverside plugin. The plugin initiates the external authentication and if valid, returns a tmp user with rights to the application. The application then login using the temp account.
Why is it you cannot do the extra validation in a Smart Client plugin?
I think it’s not secure enough. I’d rather have the user to be unable to access the system entirely instead of deleting the plugin and bypassing the auth mechanism.
Ok. If you are using external launch application anyways why not just have it know a permanent account (potentially created by itself) and have it pass the login parameters to the Smart Client when it launches it? The user would not have access to the Milestone credentials then…
A user with some programming knowledge would probably be able to reverse enginner my code and find a encryption-key, along with the saved “super account”. In my current scope, I’m not comfortable with that kind of potential backdoor.
OK. If you are at that level of security then your proposal of the temporary client could be an option. You will need to do a bit of coding regarding configuring the user, but you should be able to find some inspiration in the Surveillance Cloud component sample (which among other things creates a user and configures some rights for it).
Alright, thanks!
I seem to be stuck. I’ve managed to have the app request a login and the plugin creates a user, assign the role and return the credentials, but the login doesn’t work. I can clearly see that the user exists and is assigned to the correct role in the Management Client, but I’m getting “Connection failed. Check username and password” when I try to login. How can I troubleshoot this?
If you try manually to login with the same credentials, does it then work?
Nope!
What if you manually create a user and assigns it to the same role - can you then log in?
Yes!
It even shows up in the logs.
I just tried creating a basic user using the configuration API, adding it to a role and then logging in to the Smart Client and it worked like a charm.
My only idea is that the password has become something else than you expected. Could you please try to manually change the password of the code-generated user in the Management Client and then try to log on again?