GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2023-10-16T20:31:28Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/366269Authentication of new users from Ldapmain causing "Undefined method `provider...2023-10-16T20:31:28ZStefan HohnsteinAuthentication of new users from Ldapmain causing "Undefined method `provider' for nil:nilclass" when sign-up restrictions are in place
### Summary
Authentication of new users from Ldapmain causing "Undefined method `provider' for nil:nilclass" when sign-up restrictions are in place **and** this is the first time the ldap user tries to sign-in on the gitlab instance.
...
### Summary
Authentication of new users from Ldapmain causing "Undefined method `provider' for nil:nilclass" when sign-up restrictions are in place **and** this is the first time the ldap user tries to sign-in on the gitlab instance.
Issue was already reported in omnibus-gitlab#4735 but closed by the creator. We are still experience this issue.
### Steps to reproduce
1. Use gitlab instance with LDAP connection set up.
2. LDAP users do have email domain `mycompany.com` or `*.mycompany.com` and automatic "non-blocked" account creation is enabled for LDAP users.
3. Setup sign-up restrictions
- Allow sign-up for non-ldap users for specific domains
- Example:
- `externals.com`
- `*.externals.com`
4. A ldap user with assigned email `john.doe@mycompany.com` is using LDAP login the first time and uses valid credentials.
5. Step before will cause
1. the Error message "Undefined method `provider' for nil:nilclass" if John Doe never signed in on this gitlab instance
1. No error if John Doe already signed in before without the sign-up restrictions in place.
We are currently running Gitlab 14.9.3 from docker image `gitlab/gitlab-ee:latest` an can produce the issue reported.
The proposal from @rodrigito on omnibus-gitlab#4735 to whitelist the ldap email domains is a workaround we currently use.
### What is the current *bug* behavior?
The Error message "Undefined method `provider' for nil:nilclass" if an LDAP user never signed in on this gitlab instance
### What is the expected *correct* behavior?
1. LDAP User successfully sign in without error message.
2. If this is the first time of the ldap user signing in: The gitlab account is created automatically according to the gitlab instance configuration.
### Relevant logs
<details>
<summary> Relevant logs </summary>
<pre>
2022-04-22T14:49:49.205Z: (ldapmain) Callback phase initiated.
2022-04-22T14:49:50.015Z: (ldapmain) Authentication failure! invalid_credentials: OmniAuth::Strategies::LDAP::InvalidCredentialsError, Invalid credentials for john.doe@mycompany.com
2022-04-22T14:50:04.650Z: (ldapmain) Callback phase initiated.
2022-04-22T14:50:05.391Z: (LDAP) Error saving user XXXXXXXXXXXXXXXXXXXXXXXXX (john.doe@mycompany.com): ["Email is not allowed for sign-up. Please use your regular email address. Check with your administrator."]
2022-04-22T14:50:05.395Z: (ldapmain) Authentication failure! ldap_error: NoMethodError, undefined method `provider' for nil:NilClass
2022-04-22T15:01:19.653Z: (ldapmain) Callback phase initiated.
2022-04-22T15:01:19.879Z: (LDAP) Error saving user XXXXXXXXXXXXXXXXXXXXXXXXX (john.doe@mycompany.com): ["Email is not allowed for sign-up. Please use your regular email address. Check with your administrator."]
2022-04-22T15:01:19.884Z: (ldapmain) Authentication failure! ldap_error: NoMethodError, undefined method `provider' for nil:NilClass
2022-04-22T15:01:34.795Z: (ldapmain) Callback phase initiated.
2022-04-22T15:01:35.070Z: (LDAP) saving user ohn.doe@mycompany.com from login with admin => false, extern_uid => XXXXXXXXXXXXXXXXXX
2022-04-22T15:01:35.083Z: Instantiating Gitlab::Auth::Ldap::Person with LDIF:
2022-04-22T15:10:54.286Z: (ldapmain) Callback phase initiated.
</pre>
</details>
### Details of package version
<details>
<summary>Provide the package version installation details</summary>
<pre>
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-============================================================
un gitlab-ce <none> <none> (no description available)
ii gitlab-ee 14.9.3-ee.0 amd64 GitLab Enterprise Edition (including NGINX, Postgres, Redis)
</pre>
</details>
### Environment details
* Operating System: CentOS 7.7
* Installation Target:
* Other: docker
* Installation Type:
* New Installation
* Is there any other software running on the machine: no
* Is this a single or multiple node installation? Single
* Resources
* CPU: Intel(R) Xeon(R) Gold 6142 CPU @ 2.60GHz`
* Memory total: 16266568 kB
### Configuration details
<details>
<summary> Provide the relevant sections of `/etc/gitlab/gitlab.rb` </summary>
```ruby
gitlab_rails['ldap_servers'] = YAML.load <<-EOS
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: 'ldap.mycompany.com'
port: 389
uid: 'mail'
bind_dn: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
password: 'XXXXXXXXXXXX'
encryption: 'plain'
active_directory: true
allow_username_or_email_login: false
block_auto_created_users: false
base: 'XXXXXXXXXXXXXX'
user_filter: '(&(objectCategory=person)(objectClass=user))'
attributes:
username: 'mailNickname'
name: 'displayName'
first_name: 'givenName'
last_name: 'sn'
EOS
```
Front-end configuration
`Allowed domains for sign-ups`:
<pre>
externals.com
*.externals.com
</pre>
</details>https://gitlab.com/gitlab-org/gitlab/-/issues/350154OAuth2 permission granting screen needs an overhaul2023-10-16T20:33:37ZDaniel MoraOAuth2 permission granting screen needs an overhaul## Problem
When using an OAuth integration, the authentication screen is really not good.
| Authorization | Not signed in |
| ------ | ------ |
| ![Screenshot_2021-12-08_at_12.36.46](/uploads/04744ffc3d7b6da76352bf5b924be77f/Screenshot_...## Problem
When using an OAuth integration, the authentication screen is really not good.
| Authorization | Not signed in |
| ------ | ------ |
| ![Screenshot_2021-12-08_at_12.36.46](/uploads/04744ffc3d7b6da76352bf5b924be77f/Screenshot_2021-12-08_at_12.36.46.png) | ![Screen_Shot_2022-02-04_at_12.07.22_PM](/uploads/5cc137037df1f75590eeeec1527f6767/Screen_Shot_2022-02-04_at_12.07.22_PM.png) |
## Proposal
I suggest we create a new screen specific for this use case.
![V4](/uploads/8bb9e44d4b656da6fc944a42df7113f9/V4.png)
#### Conditions
- User is currently logged into GitLab
- User is not currently logged into GitLab
- 2FA state?
#### [✏️ Figma work file](https://www.figma.com/file/1ZjXlw4W1RmJuys04T2UBc/%23350154-OAuth2-permission-granting-screen?node-id=30%3A2380)
#### Examples
| Account list | log in for unlisted account |
| ------ | ------ |
| ![1](/uploads/6e604b55ddbb3f3442fd611b7cc1990d/1.jpg) | ![2](/uploads/b6cced07e505b2241da06f8cd890875c/2.jpg) |Next 1-3 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/224451Docs - product feedback: multiple generic 'openid_connect' providers2023-10-16T20:46:28ZAMS DeloitteDocs - product feedback: multiple generic 'openid_connect' providersDescribe what you would like to see improved.
Add capability for multiple generic 'openid_connect' providers.
<!-- Don't edit below this line -->Describe what you would like to see improved.
Add capability for multiple generic 'openid_connect' providers.
<!-- Don't edit below this line -->https://gitlab.com/gitlab-org/gitlab/-/issues/34123Search project snippets with ES and external authorization2022-05-31T11:54:12ZMarkus KollerSearch project snippets with ES and external authorization### Problem to solve
<!-- What problem do we solve? -->
https://gitlab.com/gitlab-org/gitlab/merge_requests/18459 adds support for searching project snippets with ES in a global search, but excludes project snippets when [External auth...### Problem to solve
<!-- What problem do we solve? -->
https://gitlab.com/gitlab-org/gitlab/merge_requests/18459 adds support for searching project snippets with ES in a global search, but excludes project snippets when [External authorization control](https://docs.gitlab.com/ee/user/admin_area/settings/external_authorization.html#external-authorization-control-core-only) is enabled, since we only allow project-level searches in that case, but also don't support snippets yet when searching on the project level.
https://gitlab.com/gitlab-org/gitlab/issues/18991 and/or https://gitlab.com/gitlab-org/gitlab/issues/20963 will add support for searching project snippets when searching on the project level. At this point we should revisit the logic in `Elastic::Latest::SnippetClassProxy#filter_project_snippets`, and include project snippets when only a single project is selected.
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
All users on instances with External Authorization enabled.
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
For non-ES project-level searches through the DB, this might already work as we'll be going through `SnippetsFinder#snippets_for_a_single_project`.
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
Include project snippets when searching through ES on the project level with External Authorization enabled.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?-->
Make sure the External Authorization check for the searched project is performed, this should already happen with the existing code in the [`SearchController`](https://gitlab.com/gitlab-org/gitlab/blob/b70abe63aa7648c7c14c9d60fd5aea645d870188/app%2Fcontrollers%2Fsearch_controller.rb#L19) which authorizes the project in the [`SearchService`](https://gitlab.com/gitlab-org/gitlab/blob/b70abe63aa7648c7c14c9d60fd5aea645d870188/app%2Fservices%2Fsearch_service.rb#L18).
For global and group-level ES searches, project snippets should continue to be excluded when External Authorization is enabled.
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
- Navbar searches are currently tracked through `Gitlab::UsageDataCounters::SearchCounter`, this could be extended to include the search level (global/group/project).
- Usage of the External Authorization feature doesn't seem to be tracked at all, this could be added to `Gitlab::UsageData` as well.
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
External Authorization is in Core while Elasticsearch is available in Starter and up, so this feature should be implemented for Starter.
External Authorization is not available on gitlab.com.
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30093External Authorization Cache should be customizable2023-10-16T20:52:05ZguilhoxExternal Authorization Cache should be customizableHello! As stated in [this forum post](https://forum.gitlab.com/t/external-authorization-request-cache/27899), we've been trying to use the External Authorization feature in our repositories, but the cache for that validation has a rather...Hello! As stated in [this forum post](https://forum.gitlab.com/t/external-authorization-request-cache/27899), we've been trying to use the External Authorization feature in our repositories, but the cache for that validation has a rather big timeout value, as seen [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/external_authorization/cache.rb) in the `VALIDITY_TIME` value, which is apparently not customizable.
In our vision, it could be interesting to change that value to something smaller, so that when a user has no authorization, they don't have to wait another 6 hours to be able to access that same project, nor we'd need to force expiration into Redis. If there is already a way of doing that, it should be stated in the [docs](https://docs.gitlab.com/ee/user/admin_area/settings/external_authorization.html) as well.https://gitlab.com/gitlab-org/gitlab/-/issues/9292Custom scopes for GitLab as OpenID Connect identity provider2023-10-16T20:55:08ZPhilippe GagnonCustom scopes for GitLab as OpenID Connect identity provider### Problem to solve
GitLab can currently act as an OIDC provider. However, currently OIDC scopes are hardcoded and it is not possible to add custom scopes.
It may be desirable for Gitlab to allow project maintainers to attach custom s...### Problem to solve
GitLab can currently act as an OIDC provider. However, currently OIDC scopes are hardcoded and it is not possible to add custom scopes.
It may be desirable for Gitlab to allow project maintainers to attach custom scopes to CI and deploy tokens. This could allow CI/CD processes to easily authenticate with external systems without having to deal with shared secrets when a better alternative is available.
### Target audience
DevOps Engineer, Software Developer
### Further details
n/a
### Proposal
I would propose that Gitlab allow project maintainers to add custom scopes to CI and deploy tokens.
One use case for me would be to have Gitlab CI authenticate against an internal pypiserver instance which we use to store our internal python packages, without having to use a shared secret between the two systems.
My pypiserver instance could act as an OIDC client, and my Gitlab CI jobs could authenticate against it with a valid access token, and authorize with an agreed upon scope i.e. `<project-slug>-pypi` or whatever.
### What does success look like, and how can we measure that?
As a GitLab user, I would like to be able to add custom scopes to CI and deploy tokens.
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/22987Error 500 logging in with Spnego2022-09-14T18:19:12ZDiana StanleyError 500 logging in with Spnegohttps://gitlab.zendesk.com/agent/tickets/98470
This customer is running GitLab 10.5.3-ee. Their Kerberos Spnego login is working, however sometimes it throws a 500 error with this backtrace:
```
Started GET "/users/auth/kerberos_spnego...https://gitlab.zendesk.com/agent/tickets/98470
This customer is running GitLab 10.5.3-ee. Their Kerberos Spnego login is working, however sometimes it throws a 500 error with this backtrace:
```
Started GET "/users/auth/kerberos_spnego/callback" for 134.253.70.138 at 2018-06-21 07:18:18 -0600
NoMethodError (undefined method `split' for nil:NilClass):
lib/gitlab/middleware/multipart.rb:95:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/middleware/read_only.rb:31:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
```
The spnego login succeeds and the user is logged in. I haven't really figured out the secret sauce, because sometimes the spnego login succeeds without this error. They had a valid ticket in all cases.https://gitlab.com/gitlab-org/gitlab/-/issues/5379Redesign Group SAML settings instructions2023-10-16T20:57:53ZJames Edwards-JonesRedesign Group SAML settings instructions## What
1. Split instructions on Group SAML steps into numbered steps with instructions next to each step
2. Consider expanding on instructions for required assertions and having this as the second step
## Why
1. Large amount of text ...## What
1. Split instructions on Group SAML steps into numbered steps with instructions next to each step
2. Consider expanding on instructions for required assertions and having this as the second step
## Why
1. Large amount of text instructions can make it hard to scan for where to start
2. Assertions are a large part of the setup and one of the key things SAML admins will need to know. This will help avoid us redirecting them to the docs, and help avoid the chance this step is missed. When we add ability to control access levels with assertions this will also help users discover this functionality.
## Design
| Original | New Design |
|----------|------------|
| ![Screenshot-2018-3-17_SAML_Single_Sign_On_Settings___my-saml-group__original_](https://gitlab.com/gitlab-org/gitlab-ee/uploads/6d905d3a0b52c10cb52304b6380ba8a0/Screenshot-2018-3-17_SAML_Single_Sign_On_Settings___my-saml-group__original_.png) | |
## Previous discussion
@jamedjo in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4549?view=inline#note_63905527:
>>>
When I see that large wall of text it feels hard to scan for where to start, and was thinking the above might help users skip to the URLs.
Could some of this text be moved to documentation?
Maybe for a future design iteration we'd split this into numbered steps keeping descriptive text alongside each stage:
1. Set up your identity provider, using the URLs below when asked. (See documentation for popular services)
- Assertion Consumer Service URL
- Issuer
1. Set up required assertions. Also known as claims or attributes, see documentation for further details
- NameID: Must be configured to ...
- Email: Is required
- Optional fields: name, first_name, last_name
1. Configure GitLab with fields below:
- SSO URL
- Fingerprint
>>>
@pedroms in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4549?view=inline#note_64196724:
>>>
@jamedjo thanks for sharing your feedback and explorations. I agree that the numbered steps would be ideal. And maybe even collapsing the setup info after the first setup, so you don't have to see it every time you visit the integration page.
Currently, I feel like having the setup text and the copy-paste info together helps group the necessary elements to get started. In the future, we'll have to improve this, but let's keep it as it is for this iteration.
>>>
## Related
- https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4549?view=inline#note_63905527
- https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4549?view=inline#note_63905527Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/4831Validate the external authorization is only called once per request2020-08-14T15:55:54ZBob Van Landuytbob@gitlab.comValidate the external authorization is only called once per requestWe should avoid multiple calls to the external authorization service within a single request.
Since the call could be triggered by a simple `can?(current_user, :read_project, project)` it's easy to miss a new call.
We could use the `Re...We should avoid multiple calls to the external authorization service within a single request.
Since the call could be triggered by a simple `can?(current_user, :read_project, project)` it's easy to miss a new call.
We could use the `RequestStore` in development & test to track the number of calls and raise an exception if it occurs more than once.Backlog