Additional authentication sources / additional gitea modules #4301

New Issue

GiteaMirror · 2025-11-02T05:45:15-06:00

GiteaMirror commented

2025-11-02 05:45:15 -06:00

Originally created by @bryanpedini on GitHub (Nov 13, 2019).

Gitea version (or commit ref): 1.9.4 (doesn't matter)
Git version: 1.8.3.1 (doesn't matter)
Operating system: CentOS 7 - 3.10.0-957.el7.x86_64 (doesn't matter)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:
- Can someone finally explain me what is this? :P

Description

I am developing a sort of SSO for all my websites in PHP, functionality is basics and as easy as it could get (currently login, logout and stay-logged-in functions only):

origin website looks under first party cookies, if no token is found, it redirects the user to the SSO login page, if a token is found the website makes a requesto to the SSO agent to "validate" the token and it's expiration and receive username/email or false, logout consists of the removal of one login token from the token table in the database (website initiate the logout request to the SSO agent and waits confirmation reply, at which can delete the 1st party cookie for the token), token validation is also straight forward, as it only consists to check a unique token to a matching user and pass that user information to the requesting website.
As soon as I get the first version working, it will be published open source on my gitea server.
Eventually a secret token will be introduced to protect users' and websites' data so a token is validated twice since the validation request is performed by the origin website server itself at server-to-server level without user noticing. (SSO agent also checks IP for origin website against website fqdn and administrator-specified IP ranges, so website administrators can specify only their own servers as allowed and nobody else will be able to request validations in behalf of that website or domain)

Now question is: is it possible to request SSO addon to gitea / develop my own authentication module and add it under the auth sources in site administration?
Well, second part of the question could be a totally separate issue / request, like "can I develop additional modules to integrate in Gitea" or someting like that...

Feel free to point out mistakes, suggestions or improvements, please do that, developers tend to think that their work is perfect until someone unmounts it entirely with a single flat screwdriver, suggestions are always appreciated.
Thanks in advance for the interest.

Originally created by @bryanpedini on GitHub (Nov 13, 2019). - Gitea version (or commit ref): 1.9.4 (doesn't matter) - Git version: 1.8.3.1 (doesn't matter) - Operating system: CentOS 7 - 3.10.0-957.el7.x86_64 (doesn't matter) - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: - Can someone finally explain me what is this? :P ## Description I am developing a sort of SSO for all my websites in PHP, functionality is basics and as easy as it could get (currently login, logout and stay-logged-in functions only): origin website looks under first party cookies, if no token is found, it redirects the user to the SSO login page, if a token is found the website makes a requesto to the SSO agent to "validate" the token and it's expiration and receive username/email or `false`, logout consists of the removal of one login token from the token table in the database (website initiate the logout request to the SSO agent and waits confirmation reply, at which can delete the 1st party cookie for the token), token validation is also straight forward, as it only consists to check a unique token to a matching user and pass that user information to the requesting website. As soon as I get the first version working, it will be published open source on my gitea server. Eventually a secret token will be introduced to protect users' and websites' data so a token is validated twice since the validation request is performed by the origin website server itself at server-to-server level without user noticing. (SSO agent also checks IP for origin website against website fqdn and administrator-specified IP ranges, so website administrators can specify only their own servers as allowed and nobody else will be able to request validations in behalf of that website or domain) Now question is: is it possible to request SSO addon to gitea / develop my own authentication module and add it under the auth sources in site administration? Well, second part of the question could be a totally separate issue / request, like "can I develop additional modules to integrate in Gitea" or someting like that... Feel free to point out mistakes, suggestions or improvements, please do that, developers tend to think that their work is perfect until someone unmounts it entirely with a single flat screwdriver, suggestions are always appreciated. Thanks in advance for the interest.

GiteaMirror closed this issue

2025-11-02 05:45:15 -06:00

GiteaMirror commented

2025-11-02 05:45:16 -06:00

@guillep2k commented on GitHub (Nov 13, 2019):

There's some work being done here #8463. Even if it's Windows specific, it should be useful as a base for something more generic.

@guillep2k commented on GitHub (Nov 13, 2019): There's some work being done here #8463. Even if it's Windows specific, it should be useful as a base for something more generic.

GiteaMirror commented

2025-11-02 05:45:16 -06:00

@bryanpedini commented on GitHub (Nov 14, 2019):

Thanks for the suggestions @guillep2k.
I read from that PR that it is possible to integrate more custom modules onto Gitea (or just migrate the official Gitea repository and integrate them on your own and just use them); but also I see, as you also pointed out on that PR, that PAM authentication on Linux is already present, and since I have already configured my Gitea user on my server to require a U2F key, I suppose that every PAM module installed on the host OS is available through PAM (could it be U2F, Yubico-OTP, Linux users mapping to Gitea users, etc).

So basically I could write a PAM module for Linux (CentOS in my case too), publish it alongside the SSO web app / module, and just integrate the PAM module on Gitea?

@bryanpedini commented on GitHub (Nov 14, 2019): Thanks for the suggestions @guillep2k. I read from that PR that it is possible to integrate more custom modules onto Gitea (or just migrate the official Gitea repository and integrate them on your own and just use them); but also I see, as you also pointed out on that PR, that PAM authentication on Linux is already present, and since I have already configured my Gitea user on my server to require a U2F key, I suppose that every PAM module installed on the host OS is available through PAM (could it be U2F, Yubico-OTP, Linux users mapping to Gitea users, etc). So basically I could write a PAM module for Linux (CentOS in my case too), publish it alongside the SSO web app / module, and just integrate the PAM module on Gitea?

GiteaMirror commented

2025-11-02 05:45:16 -06:00

@guillep2k commented on GitHub (Nov 14, 2019):

So basically I could write a PAM module for Linux (CentOS in my case too), publish it alongside the SSO web app / module, and just integrate the PAM module on Gitea?

@Bryanpedini Definitely! You don't "integrate" the PAM module, however. You just reference it from the configuration. In my case:

Then, /etc/pam.d/gitea-pam-config:

#%PAM-1.0
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_sss.so forward_pass domains=**********
auth        required      pam_deny.so

account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_sss.so domains=**********

In my case I needed to integrate sss, so this was my config.

Note that gitea-pam-config needs to have group/other write permissions removed from it and belong to root.

@guillep2k commented on GitHub (Nov 14, 2019): > So basically I could write a PAM module for Linux (CentOS in my case too), publish it alongside the SSO web app / module, and just integrate the PAM module on Gitea? @Bryanpedini Definitely! You don't "integrate" the PAM module, however. You just reference it from the configuration. In my case: ![image](https://user-images.githubusercontent.com/18600385/68877238-83b1d000-06e4-11ea-9dad-0f13a5972d71.png) Then, `/etc/pam.d/gitea-pam-config`: ``` #%PAM-1.0 auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_sss.so forward_pass domains=********** auth required pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_sss.so domains=********** ``` In my case I needed to integrate sss, so this was my config. Note that `gitea-pam-config` needs to have group/other write permissions removed from it and belong to `root`.

GiteaMirror commented

2025-11-02 05:45:16 -06:00

@bryanpedini commented on GitHub (Nov 15, 2019):

so this was my config.

.so files... are them created by the PAM module? are them plain text files like .sh? (do you have a guide to create a PAM module?)

Note that gitea-pam-config needs to have group/other write permissions removed from it and belong to root.

Understood. Basically -rw-rw-r-- (or -rw-r--r--) and root:root, so Gitea can still read (o+r) but only root can modify? (does it need x permission?)

@bryanpedini commented on GitHub (Nov 15, 2019): > so this was my config. `.so` files... are them created by the PAM module? are them plain text files like `.sh`? (do you have a guide to create a PAM module?) > Note that `gitea-pam-config` needs to have group/other write permissions removed from it and belong to `root`. Understood. Basically `-rw-rw-r--` (or `-rw-r--r--`) and `root:root`, so Gitea can still read (o+r) but only `root` can modify? (does it need `x` permission?)

GiteaMirror commented

2025-11-02 05:45:16 -06:00

@guillep2k commented on GitHub (Nov 15, 2019):

Understood. Basically -rw-rw-r-- (or -rw-r--r--) and root:root, so Gitea can still read (o+r) but only root can modify? (does it need x permission?)

I have it -rw-r--r-- root:root. x is only needed to execute binaries and scripts, and to traverse directories.

@guillep2k commented on GitHub (Nov 15, 2019): > > Understood. Basically `-rw-rw-r--` (or `-rw-r--r--`) and `root:root`, so Gitea can still read (o+r) but only `root` can modify? (does it need `x` permission?) I have it `-rw-r--r--` `root:root`. `x` is only needed to execute binaries and scripts, and to traverse directories.

GiteaMirror commented

2025-11-02 05:45:17 -06:00

@bryanpedini commented on GitHub (Nov 15, 2019):

x is only needed to traverse directories.

That's probably why nginx cannot access /root/my/path/to/website/public even tho public is nginx:nginx and r-xr-xr--...

@bryanpedini commented on GitHub (Nov 15, 2019): > `x` is only needed to traverse directories. That's probably why nginx cannot access `/root/my/path/to/website/public` even tho `public` is `nginx:nginx` and `r-xr-xr--`...

GiteaMirror referenced this issue

2025-11-02 12:32:36 -06:00

[PR #4301] [MERGED] Add details about USER_UID and USER_GID environment variables #17324

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#4301