remote saml_metadata_document

[tomdavidson]

I would like to reference a remote document over https in creating a aws_iam_saml_provider rather than a local file, something similar to modules' source = "github.com/.... such as:

resource "aws_iam_saml_provider" "default" {
    name = "myprovider"
    saml_metadata_document = "${file("https://domain.local/idp/shibboleth")}"
}

The remote file seems especially relevant in this case - am I overlooking existing functionality?

[radeksimko]

This looks like an interesting idea. I think that adding a way to get data from remote location over HTTP(S) and/or other protocols may require a slightly more sophisticated approach though. It would almost deserve its own resource, or better - data source.

Something like this (hypothetical data source):

data "remote_file_over_http" "saml_doc" {
  url = "https://domain.local/idp/shibboleth"
  follow_redirects = true
  expected_content_type = "text/xml"
  basic_auth = "user:pass"
}

Also I think it would make even more sense to have shibboleth and other IdPs supported as Terraform providers and be able to codify the configuration on that end too. It obviously depends on IdP's APIs.

Automation FTW. 😃

[tomdavidson]

I agree, that making some cas providers would be slick, but i think the remote file resource would still have significant value. I suggest "remote_file" that supports local, http, and git just as module source does?

In my case, I want to fake it for now. This seems a bit hackish, do you have a better suggestion?

variable "saml_metadata_file" {
    default = "idp-metadata.xml"
}

resource "null_resource" "getfile" {
    provisioner "local-exec" {
        command = "curl -s -o  ${var.saml_metadata_file} https://domain.local/idp/shibboleth"
    }
}

resource "aws_iam_saml_provider" "cas" {
    name = "cas"
    saml_metadata_document = "${file("${var.saml_metadata_file}")}"
}

[radeksimko]

That might work, but you may want to define explicit dependency between null_resource and aws_iam_saml_provider otherwise Terraform would try to create null_resource and aws_iam_saml_provider at the same time and the file would be missing:

resource "aws_iam_saml_provider" "cas" {
    depends_on = ["null_resource.getfile"]
    name = "cas"
    saml_metadata_document = "${file("${var.saml_metadata_file}")}"
}

The value you'll get from such setup is arguable though. Terraform doesn't know whether the remote file has changed and it will never re-execute the provisioner (unless you explicitly taint the null_resource).

[tomdavidson]

It "works" but not unsure about best practice and convention. I added the explicit depends. It does download the file, but there is no clean up for it.

Do I need to declare the saml_metadata_file variable generally , could I add this var to null_resource.getfile? Example code?

[eric-nord]

Could this be resolved by updating HTTP DATA PROVIDER to allow application/samlmetadata+xml on line 95

We could then use something like this to access the metadata file:

data "http" "saml_metadata_document" {
  url = "https://website.com/federationmetadata/2007-06/saml_metadata.xml"

  request_headers {
    "Accept" = "application/samlmetadata+xml"
  }
}


resource "aws_iam_saml_provider" "default" {
  name                   = "${var.idp_name}"
  saml_metadata_document = "${data.http.saml_metadata_document.xml}"
}

[ghost]

This issue has been automatically migrated to hashicorp/terraform-provider-http#13 because it looks like an issue with that provider. If you believe this is not an issue with the provider, please reply to hashicorp/terraform-provider-http#13.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.