Authelia Integration

[alexkoon]

I self host a bunch of services including pigallery2, and utilise Authelia for SSO. Is there any intention of integrating with something like Authelia? Authelia provides authentication services for services, and only after authentication will it allow requests through to back end web services. This stops the 'double login' when a user has to login pass Authelia, then a login for pigallery2. I know you can turn off authentication to pigallery2 but you need this for album sharing.

Would a possible solution be to allow Authelia to pass the user via a header of 'Remote-User' - if this matches a registered pigallery2 user, assume this is 'authenticated'? This will possible also allow other similar services such as Authelia to integrate, but I only know of Authelia as that is what I am using.

[bpatrik]

Unfortunately this is not possible at the moment and I do not see a simple way to add it. The app is not prepared for SSO.

Sharing link also creates a guest user with restricted access to the gallery. I think it would be challenging to set that part up.

[alexkoon]

Hi - its been a while and I finally taken the plunge and trying to implement this feature. Note I have zero previous Typescript2 experience so bear with me.

So far added 3 new configuration items

• externalAuthenticationEnabled
• externalAuthenticationHeader
• externalAuthencationLogoutURL

I think I have this working mostly, where if its enabled, then it will check the configured header for the user and does a lookup in the PG2 users for a matching user (a pre-requisite to have the user configured in pg2). Anyway,

I am struggling with the logout - when a user clicks Logout from the menu, that calls the backend logout and I can see you delete the user object from the session. I would also like to (if configured) redirect the whole browser window to the configured logout URL. I have tried res.redirect(URL) but this does not work as the menu item does not expect the return and redirect the window.location.href.

Do you have any tips or pointers how I can redirect the whole frame to the external URL to logout after calling PG2 logout?

[bpatrik]

A q first: Would you like to push this change back to the main codebase or you are setting this up for your own use-case?
If you want to make it available for others, I would rather wait for the extension support to be available. (in 1-2 months) and it through that. We can make it sure that this can be achieved through extension. Do not worry that if you already have this at place, moving it to an extension should be mostly copy-paste.

For the implementation question:

I would use only a single source of through for being logged in. In this case authelia. So I would make sure that the logout button logs out the user from there (i.e.: replacing the logout button to log users out there).
Then the app will need to be able to detect if the user is still logged in there.

Disclaimer: I do not know authelia and never implemented SSO.

[alexkoon]

I am doing this to fit my use case and I expect this same feature would be useful for other people who self host and obtain a Single Sign On solution. So was hoping to push this back via a pull request and see if you would review integrate if possible if you wish as its your app, your branch and your choice (one of the great things about open source).

I am happy to wait until this new extension support before completing.

As to the implementation

• I was aiming to call logout on Authelia via the browser/app but am failing to do this. I only kept the existing functionality of deleting the user from the PG Session manager for completeness (and the aim of being lightweight and being able to run on a Pi) even though if serves not true purpose otherwise. A shame I can't logout - but not the end of the world here.

With respect to your extension changes - does this include 'standardising' or simplifying the URL's of resources for PG. I ask as for adding an external authentication mechanism you would need to specify URL's which do not need protection and URL's that do. For example for sharing an album in PG2, you would want the authentication mechanism to ignore authentication for those resources, otherwise any attempt to access any other album/resource would trigger the authenticator to check for permissions before either blocking or allowing.

[bpatrik]

On the extension question: yes I plan to add some simplified way to add REST endpoints with authentication.

About the orginal request:

I was playing around with selfhosted stuff and read a bit (very little) about authelia.
It seems to me that most revers proxies can use it. In that case I would just configure a reverse proxy with authelia and disable the authentication within the app.
Its good:

1. You do not have to implement it
2. Hopefully people with security experiences set it up.

I started using Nginx proxy manager front of my pigallery2 and authelia supports it:

https://www.authelia.com/integration/proxies/nginx-proxy-manager/

[alexkoon]

One of the great features I love in PG2 is the ability to share an album. Quite often I have galleries of events for external people I like to share with. A simple obfuscated link and password in PG2 works great for this. Turning off authentication in PG2 disables this brilliant feature.

I use traefik (takes more fiddling to set up but handles SSL Lets Encrypt certs simply when set up and I don't need to manage it ongoing).

The reasons I was trying to integrate a external header for the user id to pass through are
1 - Keep the album sharing capability
2 - Can map users to internal PG2 users and have PG2 authorisations (users vs admin vs guest).

Unfortunately 2.0 of PG2 has broken album sharing with a password (see #744).

Its not the end of the world if it isn't supported as I can work around this by simply keeping the main personal PG2 gallery as is and spin up another instance of PG2 on a different domain with a single album and login managed by authelia or PG2.

[bpatrik]

Turning off authentication in PG2 disables this brilliant feature.
Ahh true. The assumption is if there is no password protection, why do obfuscation or anything, the whole gallery is public.

The reasons I was trying to integrate a external header for the user id to pass through are
1 - Keep the album sharing capability
2 - Can map users to internal PG2 users and have PG2 authorisations (users vs admin vs guest).

Good point its indeed good reason.

[bpatrik]

App now support OCRID. there is a tutorial for authentik. As far as I understand authelia should be also possible

[alexkoon]

Just integrated it with Authelia and got it to work. Had to jump through a small hoop and for those in the same, I had to add a new claims_policies definition and tie the definition to the client.

identity_providers:
oidc:
## This section defines WHAT is in the token
claims_policies:
pigallery_legacy:
id_token:
- 'email'
- 'preferred_username'
- 'name'

Then under the pigallery2 client definition add

claims_policy: 'pigallery_legacy'

[Rydra]

Out of risking necromancing, @alexkoon you're a lifesaver. I've been fighting for hours trying to figure out why Authelia was giving me the error OIDC: missing username/email. After trying your fix in the last comment, I could get authelia to work!

@bpatrik we should add documentation on how to get pigallery working on authelia. Have you tried it, or you only tried with Authentik?

[bpatrik]

I only tried authentic. If someone can create a PR in the doc with athelia, I would appreciate that.

[Rydra]

@bpatrik I'd like to understand why the hack was required in the first place for authelia, since supposedly the preferred_username should be contained in the profile scope, which is sent by default.

At the bare minimum you need to set this configuration in the configuration.yaml of Authelia to make it work (at least now)

identity_providers:
  oidc:
    hmac_secret: "myhmackey"
    jwks:
      - certificate_chain: |
          ... certificate ...
        key: |
            ... private key ...
    claims_policies:
      pigallery_legacy:
        id_token:
          - "preferred_username"
    clients:
      - client_id: "pigallery"
        client_name: "PiGallery"
        client_secret: "clientsecret"
        redirect_uris:
          - "https://mydomain.org/pgapi/auth/oidc/callback"
        claims_policy: "pigallery_legacy"
        authorization_policy: "one_factor"

Adding the preferred_username explicitly in the id_token for the case of pigallery is weird since it should be already included in the profile scope. I'll investigate a bit about this and see if I can come up with a clean solution.

[Rydra]

@bpatrik where are you obtaining the preferred_username, from the id_token or the /userinfo endpoint?