Closed distributev closed 11 months ago
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.
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
Regardless are you using the official guide and configuration for nginx?
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.
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?
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.
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.
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.
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.
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).
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.
"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.
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.
"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?
"Edit: exact cookie is authelia_session in your case." thank you, I saw this after I posted.
Version
v4.37.5
Deployment Method
Docker
Reverse Proxy
NGINX
Reverse Proxy Version
1.25
Description
Using nginx as a reverse proxy when browsing to an application which is authenticated by Authelia, if the user is already signed in, it shows a form with Hi User, Logout / Authenticated instead of forwarding/loading the actual application.
Reproduction
Have few apps behind nginx, all being protected by authelia - login in app1 and using the same user browse (using the direct URL of app2) to app2 and instead of forwarding to the app it will show (authenticated/logout)
Expectations
Show/forward/load app2 when the user is already logged in.
Configuration (Authelia)
Build Information
Logs (Authelia)
Logs (Proxy / Application)
No response
Documentation
No response
Pre-Submission Checklist
[X] I agree to follow the Code of Conduct
[X] This is a bug report and not a support request
[X] I have read the security policy and this bug report is not a security issue or security related issue
[X] I have either included the complete configuration file or I am sure it's unrelated to the configuration
[X] I have either included the complete debug / trace logs or the output of the build-info command if the logs are not relevant
[X] I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the Troubleshooting Sanitization reference guide
[X] I have checked for related proxy or application logs and included them if available
[X] I have checked for related issues and checked the documentation