Apache 2.2 SSL Proxy for AEM 6.3.1.2 Author -- Can't Login | Community
Skip to main content
this-that-the-otter
this-that-the-otter
Level 4
March 30, 2018
Solved

Apache 2.2 SSL Proxy for AEM 6.3.1.2 Author -- Can't Login

  • March 30, 2018
  • 7 replies
  • 15425 views

I have an AEM 6.3.1.2 author instance configured to authenticate either locally or with LDAP. Both authentication methods work on my local machine via localhost:4502, and when moved to the Apache host and accessed with its port number :4502 -- hostname:4502, when I access it on the Apache host via the SSL proxy, I can't login with either local (admin account) or LDAP authentication.

I tried adding hostname to the referrer filter configMgr setting as well as selecting "allow empty" -- neither affected the behavior.

Login page loads with SSL but login fails.

load login page -

30.03.2018 09:26:36.190 *INFO* [qtp1289250881-9193] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials

30.03.2018 09:26:36.426 *WARN* [5.6.7.8 [1522416396423] GET /libs/granite/core/content/login.html HTTP/1.1] libs.granite.core.components.login.login$jsp j_reason param value 'unknown' cannot be mapped to a valid reason message: ignoring

30.03.2018 09:26:37.142 *INFO* [qtp1289250881-9195] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials

try to login -

30.03.2018 09:26:51.623 *INFO* [qtp1289250881-9193] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials

30.03.2018 09:26:51.992 *INFO* [qtp1289250881-3471] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials

My VirtualHost looks like this (in main httpd.conf)

NameVirtualHost 1.2.3.4:443

<VirtualHost 1.2.3.4:443>

ServerName hostname

RewriteEngine On

SSLProxyEngine On

RewriteCond %{HTTPS} off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

ProxyPass / http://hostname:4502/

ProxyPassReverse / hostname:4502/

SSLEngine on

SSLCertificateFile /etc/pki/tls/certs/xyz.crt

SSLCertificateKeyFile /etc/pki/tls/private/xyz.key

SSLCertificateChainFile /etc/pki/tls/certs/xyz.crt

</VirtualHost>

The response headers look more or less the same when I access via port and it works vs. via the SSL proxy and it does not work ... except in the proxied connection I see a few redirects to SSL, I also see a 302 for /libs/granite/csrf/token.json to http://hostname/libs/granite/core/content/login.html?resource=%2Flibs%2Fgranite%2Fcsrf%2Ftoken.json&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown ... no https not sure if that's a clue ...

Thanks for any info on what the log means and how I might resolve.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by this-that-the-otter

    Hi Jorg,

    I did look at III and changed 2 default values (see *** 's above), along with setting a header in Apache, i.e., RequestHeader set X-Forwarded-Proto "https", specified in chapter II. 

    It seems to be working now.

    I'm not sure where the PID is referenced or how it comes into play in getting this to work.

    Thanks,

    Bill

    7 replies

    this-that-the-otter
    this-that-the-otterAuthor
    Level 4
    March 30, 2018

    It looks like those info and warn messages are in the error log on successful login as well, so they probably don't give any clues.

    Here's the inspect element  from Chrome on loading the SSL proxied author ...

    (blocked:mixed-content) (hovering over shows it is an http link). On logging in, there are two more cancelled token.json showing in red - both to https.

    Thanks for any help!

    this-that-the-otter
    this-that-the-otterAuthor
    Level 4
    March 30, 2018

    Here's some output from cURL ...

    the blocked mixed content in the screen.png points to http, looks like it's getting blocked before it can redirect?

    curl -I "http://hostname/libs/granite/core/content/login.html?resource=%2Flibs%2Fgranite%2Fcsrf%2Ftoken.json&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown"

    HTTP/1.1 302 Found

    Date: Fri, 30 Mar 2018 16:15:02 GMT

    Server: Apache/2.2.15 (CentOS)

    Location: https://hostname/libs/granite/core/content/login.html?resource=%2Flibs%2Fgranite%2Fcsrf%2Ftoken.json&64334login64334=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown

    Connection: close

    Content-Type: text/html; charset=iso-8859-1

    curl -I "https://hostname/libs/granite/core/content/login.html?resource=%2Flibs%2Fgranite%2Fcsrf%2Ftoken.json&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown"

    HTTP/1.1 200 OK

    Date: Fri, 30 Mar 2018 16:15:07 GMT

    X-Content-Type-Options: nosniff

    Content-Type: text/html;charset=utf-8

    Transfer-Encoding: chunked

    Connection: close

    this-that-the-otter
    this-that-the-otterAuthor
    Level 4
    March 31, 2018

    I received a hint from Adobe Support who pointed me at this article, and mentioned I look at III and IV specifically:

    AEM redirecting user back to http if accessed through SSL terminated Load Balancer

    Everything in IV was already there by default and since it was the only instruction specifically for 6.3, there was no change. So I did the last part of II and all or III (specifically parts 2 & 3, which needed to be updated) ...

    Here are the steps listed in the above posted link (I had to do those with *** to get my Apache SSL proxy to work):

    II. Update Dispatcher /clientheaders configuration

    Refer to the documentation of your load balancer to find out which header it sets to notify downstream systems that it terminated SSL. For simplicity, in these steps we assume that the correct HTTP header is "X-Forwarded-Proto: https"

        Log in to the dispatcher server.

        Open the dispatcher farm .any configuration.

        Add the header to the /clientheaders section.

    If you are using dispatcher without a load balancer or if your load balancer or proxy fails to set the X-Forwarded-Proto header, then you can set it at the web server or dispatcher level. If you are using Apache HTTP Server, then update your HTTPS VirtualHost with this directive:

    1

    *** RequestHeader set X-Forwarded-Proto "https"

    III. Update the Header Configurations:

        Go to http://host:port/system/console/configMgr/org.apache.felix.http.sslfilter.SslFilter, and log in as administrator.

        *** Set SSL forward header to X-Forwarded-Proto.

        *** Set SSL forward value to https.

        Click Save.

    Note:

    There is no standard for reverse proxy headers that tell the back end which protocol is used. However, here are some that are known:

        Amazon ELB (Elastic Load Balancer) uses the "X-Forwarded-Proto: https" header.

        Amazon Cloudfront CDN uses "X-Cloudfront-Proto: https" header.

    IV. Update the Jetty OSGi Configuration (AEM 6.3 and later versions)

    all of these were defaults, so I didn't need to change

    On AEM 6.3 and later versions there is an addition configuration required:

        Log in to http://aem-host:port/system/console/configMgr/org.apache.felix.http.

        Enable the setting Enable Proxy/Load Balancer Connection, and save it.

        Search for Sling Authentication Service and open the configuration.

        Deselect Allow Anonymous Access.

        Click Save.

      kautuk_sahni
      Community Manager
      kautuk_sahniCommunity Manager
      Community Manager
      April 6, 2018

      Jörg Hoh​ when you get some time please have a look at this one.

      -Kautuk

      Kautuk Sahni
      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      April 6, 2018

      Hi,

      can you check chapter 3 of the referenced link as well? If I recall correctly, the PID for the SSLFilter has changed recently, so please make sure that you have set the PID for the correct service.

      Can you indicate, which request returns invalid data or an unexpected response?

      Jörg

        this-that-the-otter
        this-that-the-otterAuthorAccepted solution
        Level 4
        April 6, 2018

        Hi Jorg,

        I did look at III and changed 2 default values (see *** 's above), along with setting a header in Apache, i.e., RequestHeader set X-Forwarded-Proto "https", specified in chapter II. 

        It seems to be working now.

        I'm not sure where the PID is referenced or how it comes into play in getting this to work.

        Thanks,

        Bill

        joerghoh
        Adobe Employee
        joerghohAdobe Employee
        Adobe Employee
        April 6, 2018

        glad that it works now.

        When you have changed the configuration for PID "A" in AEM 6.2, but in AEM 6.3 the same functionality now uses PID "B" (using the very same structure and names), you have to move the configuration from A to B. And as the PID forms the names of the configurations, it should be obvious :-)

        Jörg

          Terms & ConditionsAccessibility statement

          Loading footer...