-
Notifications
You must be signed in to change notification settings - Fork 5
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
local account creation for user connected with external identity provider #45
local account creation for user connected with external identity provider #45
Conversation
26920b6
to
fedd393
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @marwanehcine, early review from my side: One conception concern on the PR is that it tightly couples oauth2 to the presence of a geOrchestra LDAP in the infrastructure. While it would probably be the case, it won't be necessary to create accounts in some cases (e.g.: DT only uses the geOrchestra LDAP for internal / m2m accounts purposes, in their case the ability to extract roles from the JSON user payload being returned by the identity provider is sufficient).
Would it be possible to add an option to the oauth2 client definitions like createNonExistingUsersInTheLDAP: true
or something ? Also asking @groldan about this.
import org.georchestra.ds.users.DuplicatedEmailException; | ||
import org.georchestra.ds.users.DuplicatedUidException; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needed imports ? no code change in the file afterwards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok will check an remove
With FranceConnect, e-mail address should not be used as a unique identifier, as same user may have a different e-mail address depending on the FranceConnect identity provider he chooses to login using FranceConnect. So we should use another unique identifier containing identity provider name and OAuth2 subject value, which I propose in this commit, so that such a user will not have 2 different Georchestra account. The problem with that is if the user login using OAuth2 with 2 different providers with same e-mail address associated, second account creation will fail because even if UID does not exists, there is another account that has the same e-mail address. We may address this problem by searching for an existing account by UID or by e-mail, taking the one which answers positively, or create a new account if all two answers negatively. I also think that we should treat theses automatically created accounts differently on some cases. The user should not be able to see his login UID, to change password, or to login using login/password form. Header should also display something specific to this case, but I do not know what at the moment. We may address this by adding a new sec-XXXXX header to forwarded requests so that services know that this is an auto-generated account. |
if (registrationId.equals("franceconnect")) { | ||
Map<String, Object> configurationMetadata = Collections.singletonMap("end_session_endpoint", | ||
"https://fcp.integ01.dev-franceconnect.fr"); | ||
map.from(configurationMetadata).to(builder::providerConfigurationMetadata); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have no choice than having hardcoded things for franceconnect unfortunately, but won't this be an issue when switching to "franceconnect-production" ? integ01.dev
sounds quite dedicated to development purposes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed during the daily, another approach needs to be tested by @marwanehcine
2fa3a88
to
d358906
Compare
hey sorry I just stumbled upon this pr right now. |
Hello @groldan, sorry if you find PR difficult to undrestand. The goal of PR is to create local LDAP account for users who connect using Google, Mel, FranceConnect. From second user login, users information will be loaded from LDAP account. |
Hello @pmauduit , I have add option "createNonExistingUsersInTheLDAP" to enable local account creation, however when createNonExistingUsersInTheLDAP=false, what about "userDetails" page, this page cannot be shown unless a local account is created and also items was not shown to user since the is no local account. |
@PropertySource("file:${georchestra.datadir}/gateway/security.yaml") | ||
@PropertySource("file:${georchestra.datadir}/default.properties") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't we still need the security.yaml file ?
@groldan why not ? The gateway is the "entrypoint" for accessing the application, it sounds as the only place being aware of who is connecting how (when it deals with user authentication / authorization & external identity providers). If we want the administrators to be able of managing external users to e.g. ban an account, promote the user to more than ROLE_USER, ... we have to keep track of them, and one solution which sounded natural to us was to create the account into the openLDAP (which is the actual reference database for our users). I think that most online services which provide the possibility to use external 3rd party identity providers do function the same way (thinking of strava, but probably applies to others, they do keep my users info attached to my google account). We are opened to discussion if you have a more relevant approach in mind |
19b6eab
to
6063186
Compare
} catch (DuplicatedUidException e) { | ||
} catch (DuplicatedEmailException e) { | ||
} catch (DataServiceException e) { | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be revisited later on ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but do you know what to do in case of Exception ? What should happen to the end user ?
clientId: 730144348959-uudptrtn5a910g8scktj7s35um9fians.apps.googleusercontent.com | ||
clientSecret: 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sensitive data to be removed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clearly
3ea122f
to
fa62071
Compare
83fe191
to
3a5d74c
Compare
On this PR, we are creating a new LDAP account for user connected using external IDP (Google, Mel, FranceConnect).
When user connect for first time, a new LDAP account is created. After that, user information (firstname, lastname...) will be read from user LDAP account.
External IDP users can modify password and connect using login/password page.
For FranceConnect, an EndSessionURL is added to perform correct logout process.
Create e new LDAP account is optional depending on property "georchestra.gateway.security.createNonExistingUsersInLDAP"