-
Notifications
You must be signed in to change notification settings - Fork 188
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
Conversation
@@ -360,95 +462,12 @@ func resourceMongoDBAtlasFederatedSettingsIdentityProviderImportState(ctx contex | |||
return oldSDKImport(federationSettingsID, idpID, d, meta) | |||
} | |||
|
|||
federatedSettingsIdentityProvider, _, err := connV2.FederatedAuthenticationApi.GetIdentityProvider(context.Background(), *federationSettingsID, *idpID).Execute() |
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.
For consistency with other resources, I am removing the non necessary code in import. Only necessary attribute to set in import is the Id
@@ -36,6 +36,35 @@ func TestAccFedDSFederatedSettingsIdentityProvider_basic(t *testing.T) { | |||
}) | |||
} | |||
|
|||
func TestAccFedDSFederatedSettingsIdentityProvider_oidcBasic(t *testing.T) { | |||
acc.SkipTestExtCred(t) |
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.
would it be possible easy to have a migration test even with acc.SkipTestExtCred(t) or it's hard to do?
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 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?
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.
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.
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.
+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.
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 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"), |
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.
can we also check for the expected value or you think it's not so important?
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 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.
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 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?
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.
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"), | ||
} |
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.
can both protocols be enabled at the same time?
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.
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
.../federatedsettingsidentityprovider/data_source_federated_settings_identity_providers_test.go
Show resolved
Hide resolved
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 { |
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.
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") { |
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.
related to a question above, can be only 1 or 2 protocols at the same time?
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.
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
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, if you only change the protocol it fails
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.
how does it fail? is it a readable error?
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.
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
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.
LGTM, small comment in import operation
Description
Adds support for new federated auth attributes to support OIDC IdP.
federated_settings_identity_provider
now supports both types of IdP: SAML and OIDC (workforce only)federated_settings_identity_provider
now supports both types of IdP: SAML and OIDC (workforce only)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:
Required Checklist:
Further comments