Skip to content
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

[#60151] enable nextcloud storages with sso strategy #17865

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from

Conversation

Kharonus
Copy link
Member

@Kharonus Kharonus commented Feb 7, 2025

Ticket

OP#60151

What are you trying to accomplish?

  • have a possibility to authenticate via token exchange

What approach did you choose and why?

  • add decision logic, which strategy to use for nextcloud storages
  • add sso user token logic with token exchange

- https://community.openproject.org/work_packages/60151
- add decision logic, which strategy to use for nextcloud storages
- add sso user token logic with token exchange
@Kharonus Kharonus requested a review from a team February 7, 2025 12:52
@Kharonus Kharonus self-assigned this Feb 7, 2025
Copy link
Contributor

@NobodysNightmare NobodysNightmare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments. In addition to them, a basic unit test for modules/storages/app/common/storages/peripherals/storage_interaction/authentication_strategies/sso_user_token.rb would make sense IMO.

@Kharonus
Copy link
Member Author

Kharonus commented Feb 10, 2025

Yep, @NobodysNightmare , I was thinking about how to test the new code.

Testing the new strategies makes definitely sense. Should we have a unit test for the nextcloud_strategies, too? There is some business logic now.

Copy link

Caution

The provided work package version does not match the core version

Details:

Please make sure that:

  • The work package version OR your pull request target branch is correct

Copy link
Contributor

@mereghost mereghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable. I left a couple of questions more out of curiosity / not knowing enough than actual blocking issues.

@@ -34,6 +36,7 @@
sequence(:mail) { |n| "bobmail#{n}[email protected]" }
password { "adminADMIN!" }
password_confirmation { "adminADMIN!" }
identity_url { nil }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Is there a case where this is filled and the user wasn't provided by a 3rd party (or the other way around)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or the other way around)

I think if a user logs in through LDAP, the identity_url is empty/nil. Not sure if this counts for what you have in mind, because in that case we present the authentication form, but we forward the password check to LDAP.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, our whole check for authentication_provider on a user goes through this property. It was missing in the factory, hence I added it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me put this other way: can we track the IdP of the user from this? Let's say we have 2 different OIDC IdPs or a mix of OIDC/SAML?

SAML also fills this value and would be absolutely worthless for us. =/ We may need to parse it somehow as it follows the slug:idp-user-id format.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, this is how it is parsed in the user model:

  def authentication_provider
    return nil if identity_url.blank?

    slug = identity_url.split(":", 2).first
    AuthProvider.find_by(slug:)
  end

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not, that I know of. Maybe we should?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yeah. We are dealing specifically with OIDC not all SSO solutions so things like SAML/LDAP.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess right now we'd want SAML users to use two-way-oauth2 instead of SSO, correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Same with LDAP.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think LDAP does not fill the identity_url.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants