-
Notifications
You must be signed in to change notification settings - Fork 606
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to use Gitlab OIDC provider - OpenIDConnectStrategy requires an authorizationURL option #4545
Comments
It should be using your manually defined value there, however, you should be able to use discovery by removing the authorization, token, and userInfo URLs. Also you usually don't need the port number in the issuer field, when I was building this the first time, my reverse proxy was causing issues forcing me to add the port for it to work. Now you should not need or want the port number in there. Updated config: {
"$schema": "http://info.meshcentral.com/downloads/meshcentral-config-schema.json",
"settings": {
"plugins":{"enabled": false},
"mongoDb": "mongodb://mongodbadmin:mysecretpassword@mongodb:27017",
"WANonly": false,
"LANonly": true,
"sessionKey": "mysecretsessionkey",
"port": 80,
"redirPort": 81,
"aliasPort": 443,
"AgentPong": 300,
"TLSOffload": true,
"SelfUpdate": false,
"AllowFraming": false,
"WebRTC": false
},
"domains": {
"": {
"title": "MeshCentral",
"title2": ".mysecretdomain.org",
"minify": true,
"NewAccounts": true,
"orphanAgentUser": "removed@mysecretdomain.org",
"localSessionRecording": false,
"userNameIsEmail": true,
"authStrategies": {
"oidc": {
"callbackURL": "https://meshcentral.mysecretdomain.org/oidc-callback",
"clientid": "myclientid",
"clientsecret": "mysecretclientsecret",
"issuer": "https://gitlab.mysecretdomain.org",
"logoutURL": "https://gitlab.mysecretdomain.org/oauth/revoke",
"newAccounts": true
}
}
}
}
} |
Great, now I'm able to login with OIDC provided by Gitlab. But, is it normal that meshcentral has no informations about my login (or email) even if email scope is available ? Moreover, as described in Gitlab documentation , profile (and maybe email ?) scope should not be needed as openid scope already provides the required informations. I've not yet tested the groups feature but it seems to be similar. Whatever, thanks for the good work and for your help :). |
Hooray 🎉
No. However it's possible GitLab has an email field in your profile that hasn't been filled out, the
From what I understand of OpenID Connect, the With that said, if I've learned anything doing this, it's that everyone has their own way of doing things. So it's possible GitLab sends those details regardless. It's also possible that in addition to the basic OpenID Connect scopes, GitLab requires some additional scopes, or for the data to be pulled from an API endpoint using the token provided from the
At a glance of the documentation, you might be able to get away with just adding the groups section. Although if mesh isn't seeing your email there might be other issues getting groups also.
Happy to help :) Please ping me if you have any other issues with OpenID Connect on MeshCentral! |
Yet my email is correctly registered in Gitlab.
I can do more tests if you want. Thanks. |
It looks like it should work, but only without adding the groups scope, which at that point we would need a custom config to parse groups and such correctly for GitLab instances. Here's the GitLab documentation regarding OpenID Connect scopes:
The Here in the documentation they mention that the
This all seems to imply the info is there and in theory should be accessable to MeshCentral already, at least for you user info like email and name. The groups present an issue as I'm rebuilding the OpenID Connect section at the moment so I'll add a GitLab preset to handle all that while I'm at it, but that won't be ready for weeks and I'm not sure how to help you now without you just using the branch I'm working on once I get a GitLab preset ready. I'm still not sure why it's not taking in your email since that claim seems to be correct. So to that end, try adding |
I've made a few tests. First, I've removed the line adding the "groups" in the scope array.
Regarding the email field, it seems indeed to be found but unfortunately, the name is not:
I've also figured out that the user list in Mesh Central seems to be messed up as once I've logged in with OIDC no users appears anymore in that list. |
It's as I feared, even without that groups scope, the custom claim required by GitLab for groups isn't being read* by the passport module. It needs to be a bit more custom to grab those groups. |
So this is partially a bug, if the user enables groups in 1.0.85, the groups scope is added regardless. So when we go to check if the group claim returned everything, it first checks to see if group scope was added, instead of checking that groups are enabled in the config. Its in webserver.js on line 7041 How it looks now// Expanded single line for easier reading
if (options.scope.indexOf('groups') >= 0) {
// If groups scope was used do this
if ( Array.isArray(profile.groups[0].value) ) {
// If groups claim value contains an array do this
user.groups = profile.groups[0].value;
} else {
// Else do this
user.groups = [profile.groups[0].value];
}
} How it should look// Expanded single line for easier reading
if (typeof domain.authstrategies.oidc.groups == 'object') {
// If groups are configured do this
if ( Array.isArray(profile.groups[0].value) ) {
// If groups claim value is an array do this
user.groups = profile.groups[0].value;
} else if ( typeof profile.groups[0].value == 'string') {
// If groups claim value is a string do this
user.groups = [profile.groups[0].value];
} else {
// Else do this
user.groups = [];
}
} This would allow you to get your groups, if GitLab didn't use groups_direct as its primary group claim. Because the module we use right now doesn't support that custom claim, it can't return anything to the groups object in MeshCentral, even when the information is seemingly available. I'm just about finished migrating this from the current OIDC node module to node-openid-client which should allow for much greater flexibility in general. In this new version of OIDC, coming soon(tm), I made some options that would allow you to set a custom group scope and claim, as well as adjust the Fixed by #4530 |
I'll setup a test instance of meshcentral and tell you how it works.
Thanks !
Le jeu. 22 sept. 2022, 18:46, mstrhakr ***@***.***> a écrit :
… So this is partially a bug, if the user enables groups in 1.0.85, the
groups scope is added regardless. So when we go to check if the group claim
returned everything, it first checks to see if group scope was added,
instead of checking that groups are enabled in the config. Its in webserver.js
on line 7041
<https://github.com/Ylianst/MeshCentral/blob/4294e55fdbff79f8a8921ebb66f0018369a8c972/webserver.js#L7041>
*How it looks now*
// Expanded single line for easier readingif (options.scope.indexOf('groups') >= 0) {
// If groups scope was used do this
if ( Array.isArray(profile.groups[0].value) ) {
// If groups claim value contains an array do this
user.groups = profile.groups[0].value;
} else {
// Else do this
user.groups = [profile.groups[0].value];
}}
*How it should look*
// Expanded single line for easier readingif (typeof domain.authstrategies.oidc.groups == 'object') {
// If groups are configured do this
if ( Array.isArray(profile.groups[0].value) ) {
// If groups claim value is an array do this
user.groups = profile.groups[0].value;
} else if ( typeof profile.groups[0].value == 'string') {
// If groups claim value is a string do this
user.groups = [profile.groups[0].value];
} else {
// Else do this
user.groups = [];
}}
This *would* allow you to get your groups, if GitLab didn't use
groups_direct as its primary group claim. Because the module we use right
now doesn't support that custom claim, it can't return anything to the
groups object in MeshCentral, even when the information is seemingly
available.
I'm just about finished migrating this from the current OIDC node module
to node-openid-client <https://github.com/panva/node-openid-client> which
should allow for much greater flexibility in general. In this new version
of OIDC, coming soon(tm), I made some options that would allow you to set a
custom group scope and claim, as well as adjust the name, email and uuid
claims as necessary.
Fixed by #4530 <#4530>
—
Reply to this email directly, view it on GitHub
<#4545 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFUQUCTIXK4665KYYWJ2Y3V7SEOVANCNFSM6AAAAAAQKO4NCA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Describe the bug
I'm trying to use a self hosted Gitlab instance as OIDC auth provider and I'm facing the following error:
Expected behavior
I want to authenticate using OIDC with my Gitlab instance as provider.
Screenshots
If applicable, add screenshots to help explain your problem.
Server Software (please complete the following information):
Client Device (please complete the following information):
Additional context
Add any other context about the problem here.
Your config.json file
Edit:
BTW, here is the openid configuration provided by gitlab:
The text was updated successfully, but these errors were encountered: