From: Carlos P. <cpa...@ce...> - 2016-06-08 18:36:41
|
On Wed 8 June 2016 19:27:38 Kalyani wrote: > Hi Carlos, > > Thanks for your inputs. However I would like to discuss the first > point. > > We had explored Tango Access Control for implementing our > authentication mechanism. The basic issue we faced for our > application was the fact that Tango Access Control uses 'System Log > In' name as the user name for authentication. Whereas, in our > application we would have multiple user credentials under same system > log in ( i.e the application user credentials are independent of the > system log in user credentials). But without using the OS authentication, I find it very difficult (impossible?) to build anything even mildly secure. And IMHO, the false security is way worse than no security at all. > Nevertheless, we thought of few > workarounds to tackle this limitation but everything failed under > multiple user login (at the same time on same machine) scenario. > Is there any way we could use Tango Access Control independent of the > system log in? I am afraid I know almost nothing about Tango Access Control . I never used it. You may try asking in the tango mailing list/ forums > > Having faced the above limitation, we had decided to look for > authentication mechanism at GUI level itself. The options you > provided are very insightful. We would explore them from our > application perspective. Just keep in mind the fact that the user will be able to copy and run modified versions of your GUI, so IMHO, the most you can do is to offer the convenience of choosing "profiles" (e.g. customised perspectives in a GUI), but you will have to accept that the user will be able to choose whatever profile he/she wants (and a application-level auth mechanism will hardly stop a determined used). Cheers, PS: if you want to continue this discussion, please reply to tau...@li... so that other people can also see it (note that if you do not want to receive the list emails, you can always configure your registration as such) > > -----Carlos Pascual <cpa...@ce...> wrote: ----- > To: tau...@li... > From: Carlos Pascual <cpa...@ce...> > Date: 06/08/2016 03:53PM > Cc: Kalyani Thigale <kal...@tc...> > Subject: Re: Help to implement access control on TAURUS based > application > > Hi Kalyani, > > I hope you do not mind me posting my reply to the users mailing list. > I think this is a topic that may interest other users as well, plus > also maybe other users have implemented something apart of what it is > distributed in Taurus. > See the rest of my reply below your question: > > > On Wed 8 June 2016 10:59:30 Kalyani wrote: > > We need to implement authentication mechanism in our control system > > application based on TANGO framework. We are looking for user level > > access control(Access for device server, devices and commands) at > > TAURUS GUI level. Are there any tools or access control mechanism > > provided by TAURUS. Could you please share the details with us. It > > would be also helpful if you could share the details of any existing > > control system that uses access control. It would be great help for > > us. > > > > There are a few related mechanisms": > > - You can interface with the Tango Access Control [1] via Taurus, but > there are no specific taurus widgets for that (although maybe someone > has already implemented them on their own). - TaurusGui [2] provides > the "lock view" mechanism (to prevent inadvertent changes of > appearance) as well as perspectives (which can be used for providing > "basic" and "expert" modes in the GUI) - You can use filters in > TaurusAttributeForm and TaurusCommandForm to avoid showing controls > for arbitrary attributes or commands [3] - There is the > TaurusLockButton [4] and the TangoDevice lock API [5] > > BUT, if what you are after is some kind of user authentication > mechanism *at Taurus GUI level* that requires the user to > authenticate before he/she can access a resource (e.g. to write a to > certain attribute) and/or access parts of a GUI (e.g., to switch to a > certain perspective, or to unlock the view), then you need to first > consider the kind of (ab)use you want to protect against: > a) Unintentional access to resources (aka "dumb user inadvertently > messing with some critical component") > b) Non-malicious but intentional attempt to bypass Taurus-based > restrictions > c) Malicious attempts to disrupt/abuse the system > > > Protecting against c) is, IMHO impossible in a Tango-based system. > Tango is "by design" insecure (communications are not authenticated > or otherwise protected, so they can be eavesdropped and tampered > with). See [1]. > Protecting against b) **may** be possible but **only at Tango level** > (i.e. using Tango Access Control). But note that this would be a > protection at Tango level, not at Taurus GUI level. Keep in mind that > a user facing a restriction in a Taurus GUI can always just copy the > GUI code, edit it to bypass the restriction and run the modified code > instead of the original. Furthermore, a user could just use PyTango, > or jive to circumvent any Taurus-imposed restrictions. > So, this leaves us with only a) as a realistic "threat" to protect > against at the Taurus level. And IMHO, confirmation messages that > require some sort of "captcha" (e.g.: "This is may be dangerous. To > confirm that you are really sure, please type 'yes please let me do > it'") are more effective and easier to implement in this case than > user authentication mechanisms. But if someone insists on going the |