Security: Difference between revisions

From MidasWiki
Jump to navigation Jump to search
(Created page with "== Access Control to a MIDAS experiment == ;Note: To prevent access by determined or malicious hackers, a firewall and/or restrictions on off-site access should be imple...")
 
No edit summary
Line 1: Line 1:
== Access Control to a MIDAS experiment ==  
== Access Control to a MIDAS experiment ==  


;Note:
    To prevent access by determined or malicious hackers, a firewall and/or restrictions on off-site access should be implemented. This kind of security can be provided by setting up Proxy Access to [[mhttpd]] .


By default, there is no restriction for any user to connect locally or remotely to a given experiment. MIDAS provides a means to setup access restrictions using the ODB in order to protect the experiment from accidental or unauthorized access.
By default, there is no restriction for any user to connect locally or remotely to a given experiment. The MIDAS system provides a means to setup access restrictions using the ODB in order to protect the experiment from accidental or unauthorized access.


There are two levels of access restriction available each of which can be enabled independently:
There are two levels of access restriction available each of which can be enabled independently:


*    To restrict write access via the web by requiring a password before any parameter can be changed.
*    To require a password before MIDAS clients can start running on the host.
*    To require a password before MIDAS clients can start running on the host.
*    To restrict write access via the web by requiring a password before any parameter can be changed.


The user can select either or both of these security features.
The user can select either or both of these security features.


;
Note that other forms of ODB access control independent of these security features is also available:
Note that other forms of ODB access control independent of these security features is also available:
*    Write access can be restricted while a run is in progress (see [[Lock when Running]] )
*    Individual keys or subtrees in the experiment's ODB can be set "read only" with the [[odbedit]] command chmod.
== How to Setup Web Access Restrictions ==
: <span style="color: red;">To prevent access by determined or malicious hackers, a firewall and/or restrictions on off-site access should be implemented. This kind of security can be provided by setting up Proxy Access to [[mhttpd]] .
</span>
<br>
The ODB [[/Experiment ODB tree #/Experiment/Security |/Experiment/Security]] subtree can also be used to restrict access to the experiment via the Web. This subtree is automatically created (if not already present) when the [[odbedit]] command webpasswd is issued as follows:
  C:\online>odbedit
  [local:Default:S]/>cd Experiment/
  [local]/>webpasswd
  Password:<xxxx>
  Retype password:<xxxx>
After running webpasswd, a new ODB key i.e. [[/Experiment ODB tree #/Experiment/Security/Web Password |/Experiment/Security/Web Password]] will
be present containing the encrypted web password.
If web access restriction is set up, the user will be requested to provide the "Web Password" when accessing the requested experiment in "Write Access" mode. The "Read Only Access" mode is still available to all users.
[local:bnqr:S]/Experiment>ls Security/
Web Password                    pon4@#@%SSDF2


*    Write access can be restricted during a run (see [[lock when Running]] )
*    Individual keys or subtrees in the experiment's ODB can be set "read only" with the [[odbedit]] command chmod.




== How to Setup Client Access Restrictions ==
== How to Setup Client Access Restrictions ==


In order to restrict access to the experiment, a password mechanism needs to be defined. This is provided by the [[/Experiment ODB tree #/Experiment/Security |/Experiment/Security" subtree in odb. This subtree is automatically created (if not already present) when the [[odbedit]] command passwd is issued as follows:
In order to restrict access to the experiment, a password mechanism needs to be defined. This is provided by the [[/Experiment ODB tree #/Experiment/Security |/Experiment/Security]] subtree in odb. This subtree is automatically created (if not already present) when the [[odbedit]] command passwd is issued as follows:


   C:\online>odbedit
   C:\online>odbedit
Line 31: Line 53:
After running the odb command "passwd", the /Experiment/Security subtree will be present.
After running the odb command "passwd", the /Experiment/Security subtree will be present.


== Allowing specific hosts/clients access without password ==
=== Allowing specific hosts/clients access without password ===


While  [[#How to Setup Client Access Restrictions|restricting access]] can make sense to deny access to outsider to a given experiment, it can be annoying for the people working directly at the back-end computer or for an automatic frontend reloading mechanism. To address this problem, specific hosts and clients can be exempt from having to supply a password before being granted full access.
While  [[#How to Setup Client Access Restrictions|restricting access]] can make sense to deny access to outsider to a given experiment, it can be annoying for the people working directly at the back-end computer or for an automatic frontend reloading mechanism. To address this problem, specific hosts and clients can be exempt from having to supply a password before being granted full access.


=== Allowed hosts ===
==== Allowed hosts ====
Hostnames to be allowed full access to the ODB are listed in the [[/Experiment ODB tree #/Experiment/Security/Allowed hosts subtree |/Experiment/Security/Allowed hosts]] subtree, e.g.
Hostnames to be allowed full access to the ODB are listed in the [[/Experiment ODB tree #/Experiment/Security/Allowed hosts subtree |/Experiment/Security/Allowed hosts]] subtree, e.g.


Line 46: Line 68:




=== Allowed programs  ===
==== Allowed programs  ====


Programs (i.e. clients) to be allowed full access to the ODB (regardless of the node on which they are running) can be listed in the
Programs (i.e. clients) to be allowed full access to the ODB (regardless of the node on which they are running) can be listed in the
Line 54: Line 76:
   [local]:S>create int mstat
   [local]:S>create int mstat
   [local]:S>
   [local]:S>
== How to Setup Web Access Restrictions ==
;Note :
this section is only applicable to access using the MIDAS webserver [[mhttpd]]. Access with [[odbedit]] is unaffected.
The ODB [[/Experiment ODB tree #/Experiment/Security |/Experiment/Security" subtree can also be used to restrict access to the experiment via the Web. This subtree is automatically created (if not already present) when the [[odbedit]] command webpasswd is issued as follows:
  C:\online>odbedit
  [local:Default:S]/>cd Experiment/
  [local]/>webpasswd
  Password:<xxxx>
  Retype password:<xxxx>
After running webpasswd, a new ODB key i.e. <span style="color: purple;">''Web Password''</span> will be present under the <span style="color: purple;">''/Experiment/Security''</span> subtree.
Web Password
This key specifies a separate password for the Web server access via mhttpd. If this field is active, the user will be requested to provide the "Web Password" when accessing the requested experiment in "Write Access" mode. The "Read Only Access" mode is still available to all users.
[local:bnqr:S]/Experiment>ls Security/
Web Password                    pon4@#@%SSDF2

Revision as of 16:45, 21 August 2013

Access Control to a MIDAS experiment

By default, there is no restriction for any user to connect locally or remotely to a given experiment. The MIDAS system provides a means to setup access restrictions using the ODB in order to protect the experiment from accidental or unauthorized access.

There are two levels of access restriction available each of which can be enabled independently:

  • To restrict write access via the web by requiring a password before any parameter can be changed.
  • To require a password before MIDAS clients can start running on the host.

The user can select either or both of these security features.

Note that other forms of ODB access control independent of these security features is also available:

  • Write access can be restricted while a run is in progress (see Lock when Running )
  • Individual keys or subtrees in the experiment's ODB can be set "read only" with the odbedit command chmod.


How to Setup Web Access Restrictions

To prevent access by determined or malicious hackers, a firewall and/or restrictions on off-site access should be implemented. This kind of security can be provided by setting up Proxy Access to mhttpd .


The ODB /Experiment/Security subtree can also be used to restrict access to the experiment via the Web. This subtree is automatically created (if not already present) when the odbedit command webpasswd is issued as follows:

 C:\online>odbedit
 [local:Default:S]/>cd Experiment/
 [local]/>webpasswd
 Password:<xxxx>
 Retype password:<xxxx>

After running webpasswd, a new ODB key i.e. /Experiment/Security/Web Password will be present containing the encrypted web password.

If web access restriction is set up, the user will be requested to provide the "Web Password" when accessing the requested experiment in "Write Access" mode. The "Read Only Access" mode is still available to all users.

[local:bnqr:S]/Experiment>ls Security/ Web Password pon4@#@%SSDF2


How to Setup Client Access Restrictions

In order to restrict access to the experiment, a password mechanism needs to be defined. This is provided by the /Experiment/Security subtree in odb. This subtree is automatically created (if not already present) when the odbedit command passwd is issued as follows:

 C:\online>odbedit
 [local:Default:S]/>cd Experiment/
 [local]/>passwd
 Password:<xxxx>
 Retype password:<xxxx>

After running the odb command "passwd", the /Experiment/Security subtree will be present.

Allowing specific hosts/clients access without password

While restricting access can make sense to deny access to outsider to a given experiment, it can be annoying for the people working directly at the back-end computer or for an automatic frontend reloading mechanism. To address this problem, specific hosts and clients can be exempt from having to supply a password before being granted full access.

Allowed hosts

Hostnames to be allowed full access to the ODB are listed in the /Experiment/Security/Allowed hosts subtree, e.g.

 [local]/>cd "/Experiment/Security/Allowed hosts"
 [local]rhosts>create int myhost.domain
 [local]rhosts>

where <myHost.domain> is to be replaced by the full IP address of the host requesting full clearance, e.g "pierre.triumf.ca".


Allowed programs

Programs (i.e. clients) to be allowed full access to the ODB (regardless of the node on which they are running) can be listed in the /Experiment/Security/Allowed programs subtree,

 [local]/>cd "/Experiment/Security/Allowed programs"
 [local]:S>create int mstat
 [local]:S>