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

feat: Adds support to new Federated Auth parameters for OIDC #1874

Merged
merged 15 commits into from
Jan 30, 2024

Conversation

oarbusi
Copy link
Collaborator

@oarbusi oarbusi commented Jan 25, 2024

Description

Adds support for new federated auth attributes to support OIDC IdP.

  • Resource federated_settings_identity_provider now supports both types of IdP: SAML and OIDC (workforce only)
  • Data source federated_settings_identity_provider now supports both types of IdP: SAML and OIDC (workforce only)
  • Data source federated_settings_identity_providers now returns both types of IdP: SAML and OIDC (workforce only)

Link to any related issue(s): https://jira.mongodb.org/browse/CLOUDP-220798

Type of change:

  • Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
  • New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR.
  • Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR.
  • This change requires a documentation update
  • Documentation fix/enhancement

Required Checklist:

  • I have signed the MongoDB CLA
  • I have read the contribution guidelines
  • I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
  • I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
  • I have added any necessary documentation (if appropriate)
  • I have run make fmt and formatted my code
  • If changes include deprecations or removals, I defined an isolated PR with a relevant title as it will be used in the auto-generated changelog.
  • If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

@@ -360,95 +462,12 @@ func resourceMongoDBAtlasFederatedSettingsIdentityProviderImportState(ctx contex
return oldSDKImport(federationSettingsID, idpID, d, meta)
}

federatedSettingsIdentityProvider, _, err := connV2.FederatedAuthenticationApi.GetIdentityProvider(context.Background(), *federationSettingsID, *idpID).Execute()
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

For consistency with other resources, I am removing the non necessary code in import. Only necessary attribute to set in import is the Id

@oarbusi oarbusi marked this pull request as ready for review January 29, 2024 14:15
@oarbusi oarbusi requested a review from a team as a code owner January 29, 2024 14:15
@@ -36,6 +36,35 @@ func TestAccFedDSFederatedSettingsIdentityProvider_basic(t *testing.T) {
})
}

func TestAccFedDSFederatedSettingsIdentityProvider_oidcBasic(t *testing.T) {
acc.SkipTestExtCred(t)
Copy link
Member

Choose a reason for hiding this comment

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

would it be possible easy to have a migration test even with acc.SkipTestExtCred(t) or it's hard to do?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I would say that it's not straight forward even with acc.SkipTestExtCred(t) but I am open to discussing it. Maybe as part of enabling acceptance tests in the CI we could create migration tests?

Copy link
Member

Choose a reason for hiding this comment

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

This could be good test to add to ensure no breaking changes are encountered. It can import a resource with previous version and then update to the latest and expect an empty plan.

Copy link
Collaborator

Choose a reason for hiding this comment

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

+1 with the test. Perhaps no need to block the release (and this PR) but it's a good one to have, we should actually aim at always have a test like this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I tried to add the migration test with the help of @lantoli and it seems that there is an issue when running a migration test using ExternalProvider and ImportState in the acceptance test step at the same time. We will look again after release.

Check: resource.ComposeTestCheckFunc(
testAccCheckMongoDBAtlasFederatedSettingsIdentityProvidersExists(resourceName),

resource.TestCheckResourceAttrSet(resourceName, "federation_settings_id"),
Copy link
Member

Choose a reason for hiding this comment

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

can we also check for the expected value or you think it's not so important?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think that testing that the attribute itself is set it's enough. In the unit tests in model_federated_settings_identity_provider_test.go we are already testing the values.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree with you we're using unit tests and we shouldn't really "test the other components", but think about an API change that changes a computed value (like it's been happening recently): how would we detect it if not through these tests?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point! I included some value checks in both OIDC and SAML acceptance test to check most important attributes values

samlParams := &admin.ListIdentityProvidersApiParams{
FederationSettingsId: federationSettingsID.(string),
Protocol: conversion.StringPtr("SAML"),
}
Copy link
Member

Choose a reason for hiding this comment

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

can both protocols be enabled at the same time?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

One federation can have multiple IdPs, so you can have one SAML IdP and one OIDC IdP in the same federation. But one IdP can be either SAML or OIDC, not both

return diag.FromErr(fmt.Errorf("error setting sso debug enabled (%s): %s", d.Id(), err))
}

if err := d.Set("sso_url", federatedSettingsIdentityProvider.SsoUrl); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

not specific to this PR, there are many error checks like this that seem a bit verbose and we might be able to extract to some helper functions

@@ -230,6 +295,11 @@ func resourceMongoDBAtlasFederatedSettingsIdentityProviderUpdate(ctx context.Con
return diag.FromErr(fmt.Errorf("error retreiving federation settings identity provider (%s): %s", federationSettingsID, err))
}

if d.HasChange("protocol") {
Copy link
Member

Choose a reason for hiding this comment

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

related to a question above, can be only 1 or 2 protocols at the same time?

Copy link
Member

Choose a reason for hiding this comment

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

if only one, have you tried to change the protocol and see how it's handled the attributes that can only be in one type of protocol? e.g. if just protocol changes, it would probably fail because you would need to delete the fields only used in the old protocol and add the ones used in the new one

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, if you only change the protocol it fails

Copy link
Collaborator

Choose a reason for hiding this comment

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

how does it fail? is it a readable error?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Unexpected error from the server. From looking at the code, updating protocol or trying to update from SAML to OIDC or the other way around is not possible

Copy link
Member

@AgustinBettati AgustinBettati left a comment

Choose a reason for hiding this comment

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

LGTM, small comment in import operation

@oarbusi oarbusi merged commit cf26ffe into master Jan 30, 2024
35 checks passed
@oarbusi oarbusi deleted the CLOUDP-220798 branch January 30, 2024 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants