[LON-CAPA-admin] Help understanding hosting other domains' users on our access servers

[Stuart Raeburn]

Mike,

> What traffic goes across the other ports that LON-CAPA uses (e.g. 5663) and
> is that encrypted?  Is this FERPA covered data being transmitted without
> encryption?

My suggestion would be to run the request_ssl_key.sh script (in  
/home/httpd/lonCerts) on your library server and each of your access  
servers  so you can use SSL encryption for internal LON-CAPA traffic  
via port 5663 when your servers connect to other servers in the  
network, which have also installed LON-CAPA SSL certs (and had them  
signed by the LON-CAPA Certificate Authority).

Please read the instructions in the "Internal LON-CAPA SSL" part of  
section 2.21 "Encrypting server traffic with SSL" in the domain  
coordination manual --  
https://loncapa.purdue.edu/adm/help/domain.manual.pdf -- for more  
information.

Despite the fact that this infrastructure has been a part of LON-CAPA  
since version 1.3.0 (December 2004) the number of domains using  
internal SSL is still a minority.

Note: you could also change the settings for the PerlVars:

loncAllowInsecure
londAllowInsecure

in /etc/httpd/conf/loncapa.conf from 1 to 0 to prevent LON-CAPA  
internal connections to/from the purdue servers to other LON-CAPA  
servers in the network, which have not yet installed LON-CAPA SSL certs.

However, I do not believe any other domains have so far chosen to do that.

If purdue were to do that, it would be appropriate first to give other  
domains in the network which are currently sharing their resources  
with you a chance to install internal LON-CAPA SSL keys/certs on their  
own servers, if they have not yet done that.

Even without LON-CAPA internal SSL enabled, a number of internal  
LON-CAPA transactions are encrypted. To see which those are you can  
grep for the string: encrypt: within  
/home/httpd/lib/perl/Apache/lonnet.pm

> Any idea how someone from Binghamton used our server despite our access
> nodes configured as they are?

If someone from the binghamton domain has a co-author role in an  
Authoring Space in the purdue domain then that user would be allowed  
to have a user session hosted on the purdue library server.  However,  
I think it unlikely that such a co-author role exists.

So my guess would be that this may have been possible because of a  
discrepancy between the "internet domain" listed in the  
/home/httpd/lonTabs/hosts.tab file present on one of the binghamton  
LON-CAPA servers, and the "internet domain" retrieved for the same  
LON-CAPA host from the authoritative "LON-CAPA DNS" servers at MSU,  
UIUC, and SFU.

This particular situation at binghamton was discussed on this list  
recently, see:  
http://mail.lon-capa.org/pipermail/lon-capa-admin/2015-September/003100.html

It has been my personal experience that ever since a purdue domain  
coordinator modified your domain configuration this summer to deny  
hosting of user sessions from other domains, I have been unable to  
transfer my own LON-CAPA user session (msu domain) to any of the  
purdue servers.


Stuart Raeburn
LON-CAPA Academic Consortium

Quoting Mike Budzik <mikeb at purdue.edu>:

> For hosting other domains' users, we have our access nodes set to deny all
> except the following (and none of the following are checked).  However,
> today we noticed session data files in /home/httpd/perl/tmp on one of our
> access nodes that are named with another domain.
>
> USERNAME1_binghamton_4231791afc6bb5593binghamtona6.db
> USERNAME1_binghamton_4231791afc6bb5593binghamtona6.db.lock
> USERNAME1_binghamton_4231791afc6bb5593binghamtona6_parms.db
> USERNAME1_binghamton_4231791afc6bb5593binghamtona6.state
> USERNAME1_binghamton_4231791afc6bb5593binghamtona6_symb.db
>
> USERNAME2_binghamton_4231791afc6bb5593binghamtona6.db
> USERNAME2_binghamton_4231791afc6bb5593binghamtona6.db.lock
> USERNAME2_binghamton_4231791afc6bb5593binghamtona6_parms.db
> USERNAME2_binghamton_4231791afc6bb5593binghamtona6.state
> USERNAME2_binghamton_4231791afc6bb5593binghamtona6_symb.db
>
> In the access log I think it looks like the users posted answers to some
> problems.  For example:
> POST /res/binghamton/gonzales/Postlab/analysisOfBottledWaterV3.problem
> HTTP/1.1" 200 44989 "
> https://loncapa03.purdue.edu/res/binghamton/gonzales/Postlab/analysisOfBottledWaterV3.problem
>
> POST /res/binghamton/gonzales/Postlab/SimultaneousAnalysis.problem
> HTTP/1.1" 200 56842 "
> https://loncapa02.purdue.edu/res/binghamton/gonzales/Postlab/SimultaneousAnalysis.problem
>
> Any idea how someone from Binghamton used our server despite our access
> nodes configured as they are?
>
> Our organization is very sensitive to FERPA issues, so I'm pretty curious
> about it.  In this case, based on the access log I could not guess which
> course the user is in.  However, if the course had been named with a course
> number/name, that would mean I could discover some roster data which is
> covered by FERPA.  What if the user used our access server to view their
> grades?
>
> What traffic goes across the other ports that LON-CAPA uses (e.g. 5663) and
> is that encrypted?  Is this FERPA covered data being transmitted without
> encryption?
>
> Thanks,
> Mike B