SSL config for AtoM 2.2

[Jim Adamson]

Hi,

I'm hoping to enable the Require SSL for all administrator functionality security feature. Does anyone know where AtoM looks for the SSL certificate once its enabled? It also looks like some extra config is required as there's nothing listening on port 443 after that setting's enabled. Does anyone have a sample config?

Thanks very much.

Jim

[Dan Gillean]

Hi Jim,

This setting is pretty basic, as I understand it - essentially, it will just force AtoM to use https URLs for authenticated users. The configuration of your SSL certificate, so those https URLs are available, is a separate issue for a system administrator to work out. I believe that if you try to login without an https URL, you will not be able to access the system - the availability of those URLs is handled by your cert.

Does that make sense?

Regards,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3019df28-3833-4fdb-954d-bcfaafa7fc96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jim Adamson]

Hi Dan,

That makes sense - thanks for the explanation!

Jim

--
You received this message because you are subscribed to a topic in the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/aGNBkOMBHnA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2B-wUUW%3DBFQvEBE0Kr5E10PgUHy5aHUmHope11dmKytrQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Jim Adamson

Systems Administrator/Developer
Collections Services
Information Services

LFA/237 | Harry Fairhurst building | University of York | Heslington | York | YO10 5DD

+44 (0)1904 323859

My calendar

Library Footprints Knowledge Base & Enquiries

Email disclaimer: https://www.york.ac.uk/docs/disclaimer/email.htm

[Jim Adamson]

Hi Dan, all,

In the end, setting up SSL was quite straight forward. I just put the certificates in /etc/nginx/ssl, added the snippet below to /etc/nginx/sites-available/atom and reloaded the nginx config.

  listen 443 ssl;

  ssl_certificate     /etc/nginx/ssl/atom.york.ac.uk.chained.crt;

  ssl_certificate_key /etc/nginx/ssl/atom.york.ac.uk.pem;

  

However, I've noticed an oddity with the SSL/Login redirection functionality that I can reproduce on both our soon-to-be-live server (with proper certificate) and our test server (with self-signed certificate). 

Expected behaviour

1/ Visit http://atom.york.ac.uk

2/ Log in via the pop-up menu at the right-hand side.

3/ Because 'Require SSL...' is enabled, I am redirected to the full page https form to re-input my email address and password.

4/ I enter this and click the Log in button.

5/ I am redirected to the referring URL from step 1. The UI shows signs that I am logged in i.e. button at top-right shows my user name.

Actual behaviour

1/ Visit http://atom.york.ac.uk

2/ Log in via the pop-up menu at the right-hand side.

3/ Because 'Require SSL...' is enabled, I am redirected to the full page https form to re-input my email address and password.

4/ I enter this and click the Log in button.

5/ I am redirected to the referring URL from step 1. The UI shows signs that I am NOT logged in i.e. button at top-right still says 'Log in'.

Interestingly, if at step one I visit https://atom.york.ac.uk instead of the plain http URL, the problem goes away i.e. I am logged in. 

I have also noticed the referring URL is stored in the login submission form as a hidden input field value. If I change this value to begin with https or simply remove the protocol + the colon (so it's "protocol-less") in browser devtools before submitting the form, then submit the form, I am correctly logged in.

Here's the relevant HTML element:

<input type="hidden" name="next" value="http://atomedge.york.ac.uk/" id="next">

I wonder if this is a bug and the value ought to be, in the above example, "//atomedge.york.ac.uk/" , so that it takes the same protocol as the form page? Is anyone else using SSL and if so have they observed this behaviour? Of course, if we turned off plain http then the problem would go away, but I'm unsure if there might be issues with this (until now, we've used solely http)

thanks,

Jim

[david]

Hi Jim,

Hmm, that is an odd bug, and a new one to me.  My best guess is that the authentication cookie is associated with the https:// protocol, and it's not accessible from an http:// URL so it looks to the browser like you are not logged in to http://atom.york.ac.uk/.

One possible solution is to add some code to rewrite or update the hidden "next" value to https: when doing the redirect in step #3.  This should be a nice small pull request if you are interested in doing a bit of programming.  Please have a look at https://wiki.accesstomemory.org/Development/Contribute_code if you are interested in contributing code to the project.  If you are interested in having Artefactual doing the programming please contact us off-list and we can provide an quote for the work.

I would avoid stripping the protocol from the URL (e.g. //atomedge.york.ac.uk/).  I'm sure most browsers will handle such URLs gracefully, but it's not strictly a correct URL.

Another possible solution is to redirect all of your AtoM traffic from http:// to https:// via your webserver.  Forcing SSL (TLS) is fairly common practice for sites that have an SSL certificate installed - the encryption overhead is fairly insignificant and the extra security has some advantages.    Most of the AtoM sites that have SSL certificates use this paradigm - my guess is I haven't heard of this bug previously because forcing SSL is so common.


Best regards,
David

[Jim Adamson]

Hi David,

Thanks for the reply. Your explanation sounds very likely to me. As much as I'd love to dive in there and correct this bug, at the moment I'm swamped with other work, and my PHP skills are pretty limited. In lieu of this I've adjusted our Nginx config to force SSL, and it works well. I'm hoping there are no AtoM-specific gotchas in relation to forcing SSL.

thanks,

Jim

--

You received this message because you are subscribed to a topic in the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/aGNBkOMBHnA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4ad05d85-de72-466e-aee9-3f96e2091da7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.