Shows Hi User, Logout / Authenticated instead of forwarding/loading the actual application

[distributev]

Shows Hi User, Logout / Authenticated instead of forwarding/loading the actual application

[james-d-elliott]

Please show the actual config, not your template. Also please indicate if you're using a third-party configuration or the official one for NGINX Proxy Manager.

[distributev]

I'm using plain nginx reverse proxy, not NGINX proxy manager. Things seems to work fine when I try to access/login to each app individually - only if I'm already logged in (from a previous app) and I walk to the URL of another app (which is also protected by authelia) I get this Authenticated / Logout screen without taking me to the actual app. The only option I have there is to logout, which is obviously not what I intend to do.

theme: light

jwt_secret: WYjiu9I50hf7TrLUxA5fSuJo1kBFJIjFENAdAW80Mi3rlDjjSMVfnOMqULe1GE4f

default_redirection_url: 'https://domain.org'

server:
  host: 0.0.0.0
  port: 9091
  read_buffer_size: 4096
  write_buffer_size: 4096
  path: "authelia"
  headers:
    csp_template: "default-src 'self'; frame-src 'none'; object-src 'none'; style-src 'self' 'nonce-${NONCE}'; base-uri 'self'; frame-ancestors 'self' http://localhost:3000 https://virgil.>

log:
  level: debug

telemetry:
  metrics:
    enabled: false

totp:
  disable: false
  issuer: authelia.com
  algorithm: SHA1
  digits: 6
  period: 30
  skew: 1
  secret_size: 32

webauthn:
  disable: false

ntp:
  version: 4
  disable_startup_check: false
  disable_failure: false

authentication_backend:
  password_reset:
    disable: false
  # How often authelia should check if there is an user update in LDAP
  refresh_interval: 1m
  ldap:
    implementation: custom
 # Pattern is ldap://HOSTNAME-OR-IP:PORT
    # Normal ldap port is 389, standard in LLDAP is 3890
    url: ldap://lldap:3890
    # The dial timeout for LDAP.
    timeout: 5s
    # Use StartTLS with the LDAP connection, TLS not supported right now
    start_tls: false
    #tls:
    #  skip_verify: false
    #  minimum_version: TLS1.2
    # Set base dn, like dc=google,dc.com
    base_dn: dc=bkstg.domain,dc=org
    username_attribute: uid
    # You need to set this to ou=people, because all users are stored in this ou!
    additional_users_dn: ou=people
    # To allow sign in both with username and email, one can use a filter like
    # (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
    users_filter: "(&({username_attribute}={input})(objectClass=person))"
    # Set this to ou=groups, because all groups are stored in this ou
    additional_groups_dn: ou=groups
    # Only this filter is supported right now
    groups_filter: "(member={dn})"
    # The attribute holding the name of the group.
    group_name_attribute: cn
    # Email attribute
    mail_attribute: mail
    # The attribute holding the display name of the user. This will be used to greet an authenticated user.
    display_name_attribute: displayName
    # The username and password of the admin user.
    # "admin" should be the admin username you set in the LLDAP configuration
    user: uid=lisagilbert,ou=people,dc=bkstg.domain,dc=org
    # Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
    password: FokdeNeorBly

password_policy:
  standard:
    enabled: false
    min_length: 8
    max_length: 0
    require_uppercase: true
    require_lowercase: true
    require_number: true
    require_special: true
  zxcvbn:
    enabled: false
    min_score: 3

access_control:
  default_policy: deny
  rules:
    - domain: 'auth.bkstg.domain.org'
      policy: "bypass"
    - domain: 'bkstg.domain.org'
      policy: "one_factor"
    - domain: '*.bkstg.domain.org'
      policy: "one_factor"

session:
  secret: UEBNCYAe0U96j23qp0aWSJF2sNHfosv8F0W0yIAH05Mfw9qPVKxaDtAHeyY6ww4y
  name: 'authelia_session'
  domain: 'bkstg.domain.org'
  same_site: 'lax'
  inactivity: '15m'
  expiration: '1h'
  remember_me_duration: '1M'

regulation:
  max_retries: 3
  find_time: 2m
  ban_time: 5m

storage:
  encryption_key: lERasLc4lDwOQicpH29SeEWH
  local:
    path: /data/db.sqlite3

notifier:
  disable_startup_check: false
  filesystem:
    filename: /notifications/notification.txt

[james-d-elliott]

Regardless are you using the official guide and configuration for nginx?

[distributev]

Yes, the official docs straight from the authelia website and/or authelia github samples. I did notice couple of small differences between configuration.yml from the authelia github repository docker example and the website documentation - not being sure which is the latest version and which I should use but there were only few cases (which I don't remember specifically) and I don't think the issue is from there.

[james-d-elliott]

Can you show a HAR and some proxy logs? Something is amiss with this. The logs to me indicate it's operating as normal but the user is being redirected back to the portal by your proxy. Are you using http:// maybe?

[distributev]

I don't know what is a HAR file and how to generate it - I'll give you more context - there is one "main" app behind nginx and few other apps also behind the same nginx - the "main" app uses iframes to show modals to the other apps (which are all behind the same nginx). Authelia protects all apps the "main" one + the other apps. Using authelia I login to the "main" app and everything works well. From the main app when I open one of the modals to the other apps (iframe based) it sees that I am already logged in but instead of showing the other app inside the modal it shows the screen "already authenticated" and the Logout option. Yes I am logged in and being already logged in I would expect to see directly the app and not the Logout option.

[james-d-elliott]

The issue is the main app is not including the auth cookies with the iframe most likely which we can't unfortunately do anything about as that is completely up to the app itself. See the link for how to create and sanitize the HAR which will confirm it.

[distributev]

Explain me something - if "the main app is not including the auth cookies with the iframe" then how come "Using authelia I login to the "main" app and everything works well. From the main app when I open one of the modals to the other apps (iframe based) it sees that I am already logged in"

if the auth cookies would be missing it would mean that, when opening the modal/iframe to other apps, I would see the Authelia login screen isn't so? (since auth cookies are missing, you said) - However I don't see the Authelia login screen I actually get the opposite the Authelia logout screen and this proves that the auth cookies are present - what I believe is that auth cookies are present and the issue is that instead of getting the second app in the iframe (since I am already logged in) I get the Authelia logout screen. So Authelia can see that I am logged in (cookies present) but instead of showing the protected app it shows the logout screen.

My understanding is that the auth cookies are present otherwise I would not see the Authelia logout screen in the iframe.

[james-d-elliott]

The picture you show is not of an iframe it's a picture of the authelia portal directly in the browser window, so the cookie is present because it's not in an iframe.

[distributev]

It's looks and happens exactly the same in an iframe - here is a screenshot with an iframe - (both app1 and app2 are behind nginx and are protected by the same instance of authelia)

Step1 - use Authelia to login to app1 => everything works

Step2 - once logged into app1 go to an iframe which is supposed to show app2 (inside app1) => instead of viewing app2 (because you are already logged in) you get a page like the below which confirms you are logged in (even inside iframe) but it is obviously not what is expected

You might say something like "iframes are not supported" but I believe securing multiple heterogeneous apps and easily integrating such apps like that is one of the main benefits of authelia (single sign-on which helps making different apps to look and feel like a single app).

[james-d-elliott]

Without a HAR as requested and lack of adequate information to replicate this I'm closing the issue. I never said iframes are not supported, I said that it's likely the iframe is not including the cookie which WE CANNOT do anything about, it's technically impossible. The application creating the iframe must choose to include the cookies. We need the HAR to confirm the actual behavior of the application so we can investigate further.

[distributev]

"it's likely the iframe is not including the cookie"

which exact cookie(s)? Can app1 do something to include "the cookie" when calling app2 iframe?

If the cookie(s) is not included how come app2 shows as logged in when the iframe with app2 is launched? How I understand it is that, without cookie(s), the iframe with the app2 will show the authelia login page and will not show the "Already logged in" and the Logout buttons. I believe the cookie(s) (which ones?) are already there in app2 iframe.

Thank you, Authelia is already good.

[james-d-elliott]

The cookie must be included in all requests to a protected application, if it is absent the redirection will occur as the user will be completely unknown. If the cookie is included by the browser but is not making it to authelia due to a proxy misconfiguration then the symptoms will be as you are experiencing too.

Edit: exact cookie is authelia_session in your case.

[distributev]

"the cookie" - which cookie?

"if it is absent the redirection will occur as the user will be completely unknown." - The user is known it says Hi Francisco and this is the correct user - which redirection you speak of, it just says Hi Francisco and it shows the Logout.

If the cookie is already there (Hi Francisco) why it is not used by Authelia? What else Authelia needs?

Nevertheless which cookie are you referring about and is there any documentation about this cookie?

[distributev]

"Edit: exact cookie is authelia_session in your case." thank you, I saw this after I posted.