date: “2016-12-01T16:00:00+02:00” title: “Authentication” slug: “authentication” sidebar_position: 10 toc: false draft: false aliases:
Both the LDAP via BindDN and the simple auth LDAP share the following fields:
Authorization Name (required)
Host (required)
mydomain.com
Port (required)
389
for LDAP or 636
for LDAP SSLEnable TLS Encryption (optional)
Admin Filter (optional)
(objectClass=adminAccount)
(memberOf=CN=admin-group,OU=example,DC=example,DC=org)
Username attribute (optional)
uid
sAMAccountName
First name attribute (optional)
givenName
Surname attribute (optional)
sn
E-mail attribute (required)
mail
Adds the following fields:
Bind DN (optional)
cn=Search,dc=mydomain,dc=com
Bind Password (optional)
User Search Base (required)
ou=Users,dc=mydomain,dc=com
User Filter (required)
%[1]s
matching parameter will be substituted with login
name given on sign-in form.(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))
(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
%[1]s
should be used instead, e.g. when
matching supplied login name against multiple attributes such as user
identifier, email or even phone number.(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))
Enable user synchronization
Adds the following fields:
User DN (required)
%s
matching parameter will be
substituted with login name given on sign-in form.cn=%s,ou=Users,dc=mydomain,dc=com
uid=%s,ou=Users,dc=mydomain,dc=com
User Search Base (optional)
ou=Users,dc=mydomain,dc=com
User Filter (required)
%[1]s
matching parameter will be substituted with login name given on sign-in
form.(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))
(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))
Uses the following fields:
Group Search Base DN (optional)
ou=group,dc=mydomain,dc=com
Group Attribute Containing List Of Users (optional)
memberUid
or member
User Attribute Listed in Group (optional)
uid
if the group objects contains a member: bender
and the user object contains a uid: bender
.dn
if the group object contains a member: uid=bender,ou=users,dc=planetexpress,dc=com
.Verify group membership in LDAP (optional)
(|(cn=gitea_users)(cn=admins))
This procedure enables PAM authentication. Users may still be added to the
system manually using the user administration. PAM provides a mechanism to
automatically add users to the current database by testing them against PAM
authentication. To work with normal Linux passwords, the user running Gitea
must also have read access to /etc/shadow
in order to check the validity of
the account when logging in using a public key.
Note: If a user has added SSH public keys into Gitea, the use of these keys may bypass the login check system. Therefore, if you wish to disable a user who authenticates with PAM, you should also manually disable the account in Gitea using the built-in user manager.
Site Administration
-> Authentication Sources
, and select
Add Authentication Source
.Authentication Type
: PAM
Name
: Any value should be valid here, use “System Authentication” if
you’d like.PAM Service Name
: Select the appropriate file listed under /etc/pam.d/
that performs the authentication desired.1PAM Email Domain
: The e-mail suffix to append to user authentication.
For example, if the login system expects a user called gituser
, and this
field is set to mail.com
, then Gitea will expect the user email
field
for an authenticated GIT instance to be gituser@mail.com
.2Note: PAM support is added via build-time flags, and the official binaries provided do not have this enabled. PAM requires that the necessary libpam dynamic library be available and the necessary PAM development headers be accessible to the compiler.
common-session-noninteractive
- this value may be valid for other flavors of
Debian including Ubuntu and Mint, consult your distribution’s documentation.
user will log into the Gitea web interface as gituser
and not gituser@mail.com
This option allows Gitea to log in to an SMTP host as a Gitea user. To configure this, set the fields below:
Authentication Name (required)
SMTP Authentication Type (required)
Host (required)
smtp.mydomain.com
Port (required)
587
Allowed Domains
gitea.io,mydomain.com,mydomain2.com
Force SMTPS
STARTTLS
extension this will be used.Skip TLS Verify
This Authentication Source is Activated
In order to log in to Gitea using FreeIPA credentials, a bind account needs to be created for Gitea:
On the FreeIPA server, create a gitea.ldif
file, replacing dc=example,dc=com
with your DN, and provide an appropriately secure password:
dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: gitea
userPassword: secure password
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
ldapmodify -h localhost -p 389 -x -D \
"cn=Directory Manager" -W -f gitea.ldif
ipa group-add --desc="Gitea Users" gitea_users
Note: For errors about IPA credentials, run kinit admin
and provide the
domain admin account password.
Log in to Gitea as an Administrator and click on “Authentication” under Admin Panel.
Then click Add New Source
and fill in the details, changing all where appropriate.
Gitea supports SPNEGO single sign-on authentication (the scheme defined by RFC4559) for the web part of the server via the Security Support Provider Interface (SSPI) built in Windows. SSPI works only in Windows environments - when both the server and the clients are running Windows.
Before activating SSPI single sign-on authentication (SSO) you have to prepare your environment:
Create a separate user account in active directory, under which the gitea.exe
process will be running (eg. user
under domain domain.local
):
Create a service principal name for the host where gitea.exe
is running with class HTTP
:
Command Prompt
or PowerShell
as a privileged domain user (eg. Domain Administrator)host.domain.local
with the fully qualified domain name (FQDN) of the server where the web application will be running, and domain\user
with the name of the account created in the previous step: setspn -A HTTP/host.domain.local domain\user
Sign in (sign out if you were already signed in) with the user created
Make sure that ROOT_URL
in the [server]
section of custom/conf/app.ini
is the fully qualified domain name of the server where the web application will be running - the same you used when creating the service principal name (eg. host.domain.local
)
Start the web server (gitea.exe web
)
Enable SSPI authentication by adding an SPNEGO with SSPI
authentication source in Site Administration -> Authentication Sources
Sign in to a client computer in the same domain with any domain user (client computer, different from the server running gitea.exe
)
If you are using Chrome or Edge, add the URL of the web app to the Local intranet sites (Internet Options -> Security -> Local intranet -> Sites
)
Start Chrome or Edge and navigate to the FQDN URL of Gitea (eg. http://host.domain.local:3000
)
Click the Sign In
button on the dashboard and choose SSPI to be automatically logged in with the same user that is currently logged on to the computer
If it does not work, make sure that:
HTTP/...
SPN for the hostLocal intranet zone
Integrated Windows Authentication
should be enabled in Internet Explorer (under Advanced settings
)Gitea supports Reverse Proxy Header authentication, it will read headers as a trusted login user name or user email address. This hasn’t been enabled by default, you can enable it with
[service]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
The default login user name is in the X-WEBAUTH-USER
header, you can change it via changing REVERSE_PROXY_AUTHENTICATION_USER
in app.ini. If the user doesn’t exist, you can enable automatic registration with ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true
.
The default login user email is X-WEBAUTH-EMAIL
, you can change it via changing REVERSE_PROXY_AUTHENTICATION_EMAIL
in app.ini, this could also be disabled with ENABLE_REVERSE_PROXY_EMAIL
If set ENABLE_REVERSE_PROXY_FULL_NAME=true
, a user full name expected in X-WEBAUTH-FULLNAME
will be assigned to the user when auto creating the user. You can also change the header name with REVERSE_PROXY_AUTHENTICATION_FULL_NAME
.
You can also limit the reverse proxy’s IP address range with REVERSE_PROXY_TRUSTED_PROXIES
which default value is 127.0.0.0/8,::1/128
. By REVERSE_PROXY_LIMIT
, you can limit trusted proxies level.
Notice: Reverse Proxy Auth doesn’t support the API. You still need an access token or basic auth to make API requests.