Re: [Svxlink-devel] auth-class
Brought to you by:
sm0svx
From: Tobias B. <sm...@us...> - 2010-05-30 13:09:01
|
On Wed, 2010-05-26 at 09:44 +0200, Adi Bier wrote: > Hi Tobias, > > I'm currently working on the auth-class and have some thoughts about > it. > If a user logs in via a normal repeater/link on RF then it's evident > that there is no security and another user is able to "highjack" the > current session so I think there is no reliable way on the "standard > analog" RF to assure that the only a authorized user sends the > request. > Otherwise it could be interesting to offer the possibility for a > multi-user login, especially for further (digital) developments, to > indicate that some hams are standby on the repeater/link. The > logged-in stations could be presented e.g. in the aprs state message. > In this case any command that need special permissions must be > commenced with the own user-ID while the user is logged in. It could > be combined with a longer logoff-timeout. I'm not sure it's a good thing to use a login to indicate that you're available. Wouldn't it be better to use something like APRStt for that. Then also visitors, that have no account, can indicate that they are QRV on the node. > Incoming EchoLink connections could be treated as trusted (no > password) and the user will be assigned to the guest-group if it has > no svxlink.conf entry. So you mean you want to send commands via chat messages or something like that from a PC (e.g. using Qtel)? > But what shall happen if an user is logging-in on different paths at > the same time (phoneline AND RF-logic)? In this case the origin > (logic) of the user request must be stored too. There will be less need to be constantly logged in if not using it as an available indicator. You log in, do your stuff and then log out. But of course, multi login would be possible to implement if needed, but don't make it more complicated than it needs to be. > If you want to configure many users, the svxlink.conf is going more > confusing due to a lot of userentries and configuration variables so I > think it's reasonable to proof the advantages of implementing a > sql-database connector. With this connector all params could be stored > in tables and are changeable on runtime, so svxlink must not be > restarted if a single value has been changed ... later. There are a > some nice webinterfaces you can use to easy change the params in an > graphical environment. Here I think on two databases: SQLite for small > local systems or postgreSQL if you have running a system with more > resources. But it's just an idea. Yes, I've also been thinking of moving the config into a DB. It has some advantages but also drawbacks. The obvious drawback is that the config become less accessible and the need for a special config tool necessary. I would not want to force users to learn SQL to be able to config SvxLink. Even if there are general web interfaces to manipulate DB:s I don't think this is a good solution. It will probably be too technical for an average user to edit the tables and the risk of doing something wrong is obvious. The correct thing would be to design a SvxLink web UI that can present the SvxLink sysop with an easy to understand interface. A DB will make it harder to config a stand alone, text mode only SvxLink node. You'd always have to bring a laptop to do administration via the web UI. Another way is to make the web UI compatible with text mode only browsers. Also, if a DB like PostgreSQL were to be utilized, the installation of SvxLink will be much harder. Especially for users that are not that familiar with Linux. Although using a DB have some advantages, we should be certain that going in that direction will add substantial value since it also may have some disadvantages. I have been thinking of adding an sqlite backend to the Async::Config class. Then it would make it easier to access the config from a web UI without changing the rest of SvxLink. Also, the option of using the text config files would still be available. Changing config "live" is something I have been thinking of as well. This could be implemented in the Async::Config class by adding a SigC signal for when a value is changed. The big job then, of course, is to adapt different parts of SvxLink to handle live config updates. 73's de SM0SVX / Tobias > > 73's de Adi, DL1HRC > > Tobias Blomberg schrieb: > > On Thursday 15 April 2010 08.56.15 Adi Bier wrote: > > > > > Hi Tobias, > > > > > > ok, I think I have understand the way. I guess something like a auth- class > > > with a small usermanagement in the svx-root or something like this should > > > done it. > > > > > > > Yes, something like that. A global authentication/authorization handler > > managing accounts, groups and allowing/disallowing access to different services > > in the cores. You may already have started to work on something different but > > anyway, I have envisioned something like the idea outlined below. > > > > Each core can have one user logged in, like a terminal, so there is one login > > handler per core. > > > > if (auth->login("123456")) {} > > user = auth->user(); > > user_id = user->id(); > > user_name = user->name(); > > email = user->cfg("EMAIL"); > > auth->logout(); > > > > Each core and its modules can register authorization items in the global > > service which can then be configured to allow or disallow an action for a > > certain user. The registration of authorization items may not be necessary but > > could be nice to have for error checking and help generation. > > > > For example, a core may register an authorization item called > > "SimplexLogic:activate_module". When a user requests activation of a module, > > the core calls a check function in the global authorization handler like: > > > > authz = AuthorizationHandler::instance(); > > if (authz->authorizationOk(user, "SimplexLogic:activate_module:EchoLink")) {} > > > > If there is a matching rule, like ".+:activate_module:EchoLink|Parrot" the > > authorizer will return "true" if the user is trying to activate module > > EchoLink or Parrot in any logic core. > > > > * One should be able to specify rules for all users, for a group of users or > > for one single user. > > > > * Anything that is not explicitly allowed is denied. > > > > * DENY is evaluated before ALLOW. > > > > * Evaluation order is: user, group, all > > > > * Each authz string is split on the colon separator and each part is evaluated > > as separate regular expressions with ^ added in the beginning and $ added at > > the end. That is, each part must match exactly. > > > > * If a rule is shorter than the expression to match and the rule match from > > the beginning of the expression, the rest is considered to match as well. So > > ".+" will match any non empty expression. ".+:activate_module" will match > > "SimplexLogic:activate_module:EchoLink". > > > > The config could look something like: > > > > [AUTH_GLOBAL] > > # All users may activate/deactivate the help and EchoLink modules and > > # connect to other EchoLink stations. > > ALLOW=".+:(de)?activate_module:Help|EchoLink", \ > > ".+:module:EchoLink:(dis)?connect" > > GROUPS=SYSOP,USER > > USERS=SM0SVX,SM0AAA,SM0BBB,SM0CCC > > > > [AUTH_GROUP_SYSOP] > > # Allow sysops to use all commands > > ALLOW=.+ > > # Except formatting the harddrive since that's too dangerous :-) > > DENY=.+:format_hd > > > > [AUTH_GROUP_USER] > > # Allow logged in users to activate and deactivate modules and to > > # run all commands in all modules. > > ALLOW=".+:(de)?activate_module",".+:module" > > > > [AUTH_USER_SM0SVX] > > ID=123 > > PASSCODE=456 > > EMAIL=sm...@my...main > > GROUPS=SYSOP > > > > [AUTH_USER_SM0AAA] > > ID=111 > > PASSCODE=123 > > EMAIL=sm...@my...main > > GROUPS=USERS > > # Allow this user to set the time > > ALLOW=.+:set_time > > > > [AUTH_USER_SM0BBB] > > ID=222 > > PASSCODE=123 > > EMAIL=sm...@my...main > > GROUPS=USERS > > > > [AUTH_USER_SM0CCC] > > ID=333 > > PASSCODE=123 > > EMAIL=sm...@my...main > > GROUPS=USERS > > > > Comments? > > > > 73's de SM0SVX / Tobias > > > > > > > > > 73´s de Adi EA3/DL1HRC > > > > > > -----Ursprüngliche Nachricht----- > > > Von: SM0SVX > > > Gesendet: 14-abr-2010 23:43:33 > > > An: Discussions about development issues > > > Betreff: Re: [Svxlink-devel] Auth-Question > > > > > > > > > > On Tuesday 13 April 2010 14:01:56 Adi Bier wrote: > > > > > > > > > Hi Tobias, > > > > > > > > > > I've a question relating to an authentication process when connecting > > > > > two or more logics together. It's needed if you want to run the > > > > > phonelogic. At the moment it's handled only in the (analogphone-) logic > > > > > itself. But I think the better solution will be to put it at a central > > > > > position, e.g. into the LogicCmds.h > > > > > > > > > > If true then I need a reference to the source-logic-object there, that > > > > > has initialized the authentication process to send voice commands > > > > > ("enter PIN", "wrong PIN",...) only to the audiopath(RX/TX-adapter) that > > > > > want's to be connected with the other logics. > > > > > At the moment it's a bit tricky for me because I think there is no easy > > > > > way to tell the LinkCmd-operator the information from where the > > > > > auth-request was initialized. > > > > > Maybe I'm totally wrong here and there is an easy solution? Do you have > > > > > an idea? > > > > > > > > > As I have said some time before I like to compare the SvxLink core with an > > > > operating system. I've been meaning to implement > > > > authentication/authorization as a service in the core. If not logged in, > > > > you are running as guest and have certain privileges. If logged in, other > > > > privileges can be added to that user or group of users, like in any OS. > > > > > > > > This could be used to access sysop functions in the link or personal > > > > functions like your voice mail or in your case access specific phone > > > > logic functions. > > > > > > > > For sensitive functions one could even implement one time passwords or > > > > something like that which is more secure. > > > > > > > > I don't know if this was an answer to your question but this is how I have > > > > envisioned how authentication/authorization should work in SvxLink, > > > > > > > > 73's de SM0SVX / Tobias > > > > > > > > > > > > > 73's de Adi, DL1HRC > > > > > > > > > ------------------------------------------------------------------------------ |