You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Django receives a request it uses its own authentication backends (along with the middleware and so on). One of this backends is the GENIRemoteUserBackend:
and is in apparent charge of checking certificates for the user that sends the request ('remote'; in this case 'xml')
E.g. root user enters Expedient and checks a specific slice detail page. The certificate for this user will be checked then, with no apparent problems.
But... When any action is performed on the VM, the user set in request.META['REMOTE_USER'] has its certificate checked. This operation returns the following exception ( some traces have been added to follow the workflow in the future ):
[Wed May 08 04:38:34 2013] [error] expedient_geni.backends.GENIRemoteUserBackend.clean_username() => username: 'xml' [before line no- 52]
[Wed May 08 04:38:34 2013] [error]
[Wed May 08 04:38:34 2013] [error] expedient_geni.backends.get_username_from_cert() => Fetching certificate for 'xml' [before line no. 17]
[Wed May 08 04:38:34 2013] [error]
[Wed May 08 04:38:34 2013] [error] sfa.trust GID.init() => create: False, subject: None, string: xml, filename: None, uuid: None, hrn: None, urn: None [before line no. 82]
[Wed May 08 04:38:34 2013] [error]
[Wed May 08 04:38:34 2013] [error] expedient_geni.backends.get_username_from_cert() => Problem with certificate for user 'xml'. Details: [('PEM routines', 'PEM_read_bio', 'bad base64 decode')] [before line no. 25]
[Wed May 08 04:38:34 2013] [error] 2013-05-08 04:38:34,801:expedient_geni.backends:WARNING
[Wed May 08 04:38:34 2013] [error] /opt/ofelia/expedient/src/wsgi/expedient/clearinghouse/../../../python/expedient_geni/backends.py:28
[Wed May 08 04:38:34 2013] [error] **** Failed to get certificate from string.
[Wed May 08 04:38:34 2013] [error] 2013-05-08 04:38:34,802:expedient_geni.backends:WARNING
[Wed May 08 04:38:34 2013] [error] /opt/ofelia/expedient/src/wsgi/expedient/clearinghouse/../../../python/expedient_geni/backends.py:29
[Wed May 08 04:38:34 2013] [error] **** Traceback (most recent call last):
[Wed May 08 04:38:34 2013] [error] File "/opt/ofelia/expedient/src/wsgi/expedient/clearinghouse/../../../python/expedient_geni/backends.py", line 18, in get_username_from_cert
[Wed May 08 04:38:34 2013] [error] gid = GID(string=cert_string)
[Wed May 08 04:38:34 2013] [error] File "/opt/ofelia/expedient/src/wsgi/expedient/clearinghouse/../../../python/sfa/trust/gid.py", line 83, in init
[Wed May 08 04:38:34 2013] [error] Certificate.init(self, create, subject, string, filename)
[Wed May 08 04:38:34 2013] [error] File "/opt/ofelia/expedient/src/wsgi/expedient/clearinghouse/../../../python/sfa/trust/certificate.py", line 269, in init
[Wed May 08 04:38:34 2013] [error] self.load_from_string(string)
[Wed May 08 04:38:34 2013] [error] File "/opt/ofelia/expedient/src/wsgi/expedient/clearinghouse/../../../python/sfa/trust/certificate.py", line 326, in load_from_string
[Wed May 08 04:38:34 2013] [error] self.cert = crypto.load_certificate(crypto.FILETYPE_PEM, parts[0])
[Wed May 08 04:38:34 2013] [error] Error: [('PEM routines', 'PEM_read_bio', 'bad base64 decode')]
[Wed May 08 04:38:34 2013] [error]
[Wed May 08 04:38:34 2013] [error] /usr/local/lib/python2.6/dist-packages/django_registration-0.7-py2.6.egg/registration/models.py:4: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[Wed May 08 04:38:34 2013] [error] import sha
[Wed May 08 04:38:35 2013] [error] /usr/lib/python2.6/dist-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken
[Wed May 08 04:38:35 2013] [error] RandomPool_DeprecationWarning)
[Wed May 08 04:38:35 2013] [error]
[Wed May 08 04:38:35 2013] [error] expedient.geni.middleware.CreateUserGID.process_request() => creating user certificate (if not already present) for request.META['REMOTE_USER']: 'xml' [before line no. 11]
[Wed May 08 04:38:35 2013] [error]
[Wed May 08 04:38:35 2013] [error] sfa.trust.gid.GID().init() => create: False, subject: None, string: None, filename: /opt/ofelia/expedient/src/python/expedient/clearinghouse/gcf-x509-user.crt/user_x509_xml.crt, uuid: None, hrn: None, urn: None [before line no. 82]
[Wed May 08 04:38:35 2013] [error]
[Wed May 08 04:38:35 2013] [error] sfa.trust.gid.GID.init() => create: False, subject: None, string: None, filename: None, uuid: None, hrn: None, urn: None [before line no. 82]
This is not due to the certificate validity:
openssl x509 -in user_x509_xml.crt -text -noout
Validity
Not Before: Oct 24 10:41:06 2012 GMT
Not After : Oct 23 10:41:06 2017 GMT
date
Wed May 8 13:52:46 CEST 2013
nor because of the permissions, because it was also chmod'ed to 777 in order to test this; and neither because of incorrect format.
This happens at least since 0.4.3 (probably much ago).
Bonus: django settings file may have something not fully correct regarding this issue. See this.
Next, you must replace the ModelBackend with RemoteUserBackend in the AUTHENTICATION_BACKENDS setting:
When Django receives a request it uses its own authentication backends (along with the middleware and so on). One of this backends is the
GENIRemoteUserBackend
:File: expedient/src/python/expedient/clearinghouse/defaultsettings/django.py
and is in apparent charge of checking certificates for the user that sends the request ('remote'; in this case 'xml')
E.g. root user enters Expedient and checks a specific slice detail page. The certificate for this user will be checked then, with no apparent problems.
But... When any action is performed on the VM, the user set in
request.META['REMOTE_USER']
has its certificate checked. This operation returns the following exception ( some traces have been added to follow the workflow in the future ):This is not due to the certificate validity:
nor because of the permissions, because it was also chmod'ed to 777 in order to test this; and neither because of incorrect format.
This happens at least since 0.4.3 (probably much ago).
Bonus: django settings file may have something not fully correct regarding this issue. See this.
But in the Django settings both the example and the one from GENI are present. Doesn't seem to have a different behavior, though.
The text was updated successfully, but these errors were encountered: