pulumi / pulumi-keycloak

A KeyCloak Pulumi resource package, providing multi-language access to KeyCloak
Apache License 2.0
36 stars 6 forks source link

validation issue when creating saml identity Provider resource with default settings #141

Open davide-talesco opened 2 years ago

davide-talesco commented 2 years ago

What happened?

Creating a basic saml identity provider with latest version of pulumi keycloak provider fails with a bunch of validation errors, while the same terraform template works as expected.

Also the example usage in nodejs sdk does not work for the same reason

Steps to reproduce

The below pulumi code fails with validation errors:

import * as pulumi from "@pulumi/pulumi";
import * as keycloak from '@pulumi/keycloak';

const realm = new keycloak.Realm(`pulumi-realm`, {
  realm: 'pulumi-realm',
  enabled: true
});

const samlIdentityProvider = new keycloak.saml.IdentityProvider(
  "pulumi-idp",
  {
    realm: realm.id,
    alias: 'pulumi-idp',
    entityId: "https://domain.com/entity_id",
    singleSignOnServiceUrl: "https://domain.com/adfs/ls/",
  }
);
image

while its analogous terraform template using keycloak terraform provider works as expected

terraform {
  required_providers {
    keycloak = {
      source = "mrparkers/keycloak"
      version = "3.8.1"
    }
  }
}

provider "keycloak" {
  client_id     = "admin-cli"
  username      = "admin"
  password      = "password"
  url           = "https://keycloak.domain.com"
}

resource "keycloak_realm" "realm" {
  realm             = "tf-realm"
  enabled           = true
}

resource "keycloak_saml_identity_provider" "realm_saml_identity_provider" {
  realm = keycloak_realm.realm.id
  alias = "tf-idp"
  entity_id                  = "https://domain.com/entity_id"
  single_sign_on_service_url = "https://domain.com/adfs/ls/"
}

I have a feeling this is due to an awkward default value to empty string being set in the upstream terraform resource schema (ie check name_id_policy_format here and the same happens to all other properties failing validation) but I do not quite understand why the terraform provider does not fail in the same way. I am willing to help open a PR to fix the issue if anyone can explain the above behaviour.

Regards, Davide

Expected Behavior

The saml identity provider is created succesfully

Actual Behavior

The resource creation fails

Versions used

IE-F56Q8641:pulumi-keycloak-sample davide_talesco$ pulumi about
CLI          
Version      3.35.1
Go Version   go1.18.3
Go Compiler  gc

Plugins
NAME      VERSION
keycloak  4.9.0
nodejs    unknown

Host     
OS       darwin
Version  12.3.1
Arch     x86_64

This project is written in nodejs: executable='/usr/local/bin/node' version='v14.18.0'

Backend        
Name           IE-F56Q8641
URL            file://~
User           davide_talesco
Organizations  

Dependencies:
NAME              VERSION
@pulumi/keycloak  4.9.0
@pulumi/pulumi    3.35.1
@types/node       14.18.21

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

lblackstone commented 2 years ago

I have a feeling this is due to an awkward default value to empty string being set in the upstream terraform resource schema (ie check name_id_policy_format here and the same happens to all other properties failing validation) but I do not quite understand why the terraform provider does not fail in the same way. I am willing to help open a PR to fix the issue if anyone can explain the above behaviour.

@jkodroff Any ideas on this?

davide-talesco commented 2 years ago

@lblackstone any idea about this?

davide-talesco commented 2 years ago

anyone looking at this?

lblackstone commented 2 years ago

@stack72 Any ideas?

jkodroff commented 2 years ago

At a glance, this may be similar to https://github.com/pulumi/pulumi-terraform-bridge/issues/577.

The provider is already forked, so I suggest that we remove the default value on the fork and see if it resolves the problem. If that works, create an issue in the Bridge that details the issue and link back to the bridge issue in the forked TF provider so we know when we can put the default back. (We want as little divergence from the original TF provider as possible.)