Closed dlethin closed 3 years ago
Hey @dlethin can I also see a redacted main.tf that includes the app/rules in question here so I can try and reproduce this issue. @richet theres a chance this may be an API thing. Once I get a hold of the main.tf from @dlethin to reproduce, I can inspect the request that gets sent to /app/:id/rules
to see if theres anything unusual.
If you would, could you also set your TF_LOG=trace and see if there are any errors or anything out of the ordinary that might help us speed up the investigation? Thanks!
I seemed to have gotten myself into a pickle where I was experimenting with latest versions of onelogin-cli
and terraform onelogin provider, thinking maybe some updates my exhibit different behavior. I experienced some weirdness which maybe I'll need to report in a separate issue, but in trying to recover back to where I was, I'm now in a situation where both onelogin terraform-import
and terraform import
or terraform apply
are just hanging on me. For example, the last few lines of running import with tracing shows this:
onelogin_saml_apps.amazon__web__services_aws-1171984: Importing from ID "1171984"...
2020/07/02 15:07:02 [TRACE] EvalImportState: import onelogin_saml_apps.amazon__web__services_aws-1171984 "1171984" produced instance object of type onelogin_saml_apps
2020/07/02 15:07:02 [TRACE] [walkImport] Exiting eval tree: onelogin_saml_apps.amazon__web__services_aws-1171984 (import id "1171984")
2020/07/02 15:07:02 [TRACE] vertex "onelogin_saml_apps.amazon__web__services_aws-1171984 (import id \"1171984\")": expanding dynamic subgraph
2020/07/02 15:07:02 [TRACE] vertex "onelogin_saml_apps.amazon__web__services_aws-1171984 (import id \"1171984\")": entering dynamic subgraph
2020/07/02 15:07:02 [TRACE] dag/walk: updating graph
2020/07/02 15:07:02 [TRACE] dag/walk: added new vertex: "import onelogin_saml_apps.amazon__web__services_aws-1171984 result"
2020/07/02 15:07:02 [TRACE] dag/walk: visiting "import onelogin_saml_apps.amazon__web__services_aws-1171984 result"
onelogin_saml_apps.amazon__web__services_aws-1171984: Import prepared!
2020/07/02 15:07:02 [TRACE] vertex "import onelogin_saml_apps.amazon__web__services_aws-1171984 result": starting visit (*terraform.graphNodeImportStateSub)
2020/07/02 15:07:02 [TRACE] vertex "import onelogin_saml_apps.amazon__web__services_aws-1171984 result": evaluating
2020/07/02 15:07:02 [TRACE] [walkImport] Entering eval tree: import onelogin_saml_apps.amazon__web__services_aws-1171984 result
2020/07/02 15:07:02 [TRACE] <root>: eval: *terraform.EvalSequence
2020/07/02 15:07:02 [TRACE] <root>: eval: *terraform.EvalGetProvider
2020/07/02 15:07:02 [TRACE] <root>: eval: *terraform.EvalRefresh
Prepared onelogin_saml_apps for import
2020/07/02 15:07:02 [TRACE] GRPCProvider: ReadResource
onelogin_saml_apps.amazon__web__services_aws-1171984: Refreshing state... [id=1171984]
2020/07/02 15:07:07 [TRACE] dag/walk: vertex "provider.onelogin (close)" is waiting for "onelogin_saml_apps.amazon__web__services_aws-1171984 (import id \"1171984\")"
2020/07/02 15:07:12 [TRACE] dag/walk: vertex "provider.onelogin (close)" is waiting for "onelogin_saml_apps.amazon__web__services_aws-1171984 (import id \"1171984\")"
2020/07/02 15:07:17 [TRACE] dag/walk: vertex "provider.onelogin (close)" is waiting for "onelogin_saml_apps.amazon__web__services_aws-1171984 (import id \"1171984\")"
...
with that last line repeating every few seconds.
Will continue to poke at this.
Disregard that last comment. I was multitasking like mad yesterday and didn't realize I had the wrong API creds pointing to a different onelogin account. On to your original question.
Here is our terraform code:
provider onelogin {
alias = "onelogin"
}
resource onelogin_saml_apps aws {
provider = onelogin
name = "Amazon Web Services (AWS)"
visible = true
parameters {
include_in_saml_assertion = false
param_key_name = "https://aws.amazon.com/SAML/Attributes/Role"
provisioned_entitlements = false
safe_entitlements_enabled = false
user_attribute_macros = ""
user_attribute_mappings = "none"
default_values = ""
label = "Role"
skip_if_blank = false
values = ""
attributes_transformations = "amazon_roles"
}
parameters {
attributes_transformations = "none"
default_values = ""
include_in_saml_assertion = false
user_attribute_macros = ""
user_attribute_mappings = "email"
values = ""
label = "Amazon Username"
param_key_name = "saml_username"
provisioned_entitlements = false
safe_entitlements_enabled = false
skip_if_blank = false
}
parameters {
skip_if_blank = false
values = ""
default_values = ""
param_key_name = "https://aws.amazon.com/SAML/Attributes/RoleSessionName"
label = "RoleSessionName"
provisioned_entitlements = false
safe_entitlements_enabled = false
user_attribute_macros = ""
user_attribute_mappings = "email"
attributes_transformations = "none"
include_in_saml_assertion = false
}
rules {
enabled = true
match = "all"
name = "RULE_1_NAME"
actions {
action = "set_role"
expression = ""
value = ["arn:aws:iam::MY_AWS_ACCOUNT_ID:role/AWS_ROLE_1_NAME"]
}
conditions {
source = "has_role"
value = "ROLE_1_ID"
operator = "ri"
}
}
rules {
enabled = true
match = "all"
name = "RULE_2_NAME"
actions {
action = "set_role"
expression = ""
value = ["arn:aws:iam::MY_AWS_ACCOUNT_ID:role/AWS_ROLE_2_NAME"]
}
conditions {
source = "has_role"
value = "ROLE_2_ID"
operator = "ri"
}
}
rules {
enabled = true
match = "all"
name = "RULE_3_NAME"
actions {
action = "set_role"
expression = ""
value = ["arn:aws:iam::MY_AWS_ACCOUNT_ID:role/AWS_ROLE_3_NAME"]
}
conditions {
source = "has_role"
value = "ROLE_3_ID"
operator = "ri"
}
}
allow_assumed_signin = false
connector_id = CONNECTOR_ID
description = ""
notes = ""
provisioning {
enabled = true
}
}
I did run terraform apply with tracing turned on. The plan was to add a third rule to the app configuration. There were no errors I could see in the output. There were some warnings which are interesting, but I don't think relevant to this reported problem:
2020/07/03 09:55:01 [WARN] Provider "registry.terraform.io/-/onelogin" produced an invalid plan for onelogin_saml_apps.amazon__web__services_aws-1171984, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .configuration: block count in plan (1) disagrees with count in config (0)
- .sso: block count in plan (1) disagrees with count in config (0)
...
2020/07/03 09:55:05 [WARN] Provider "registry.terraform.io/-/onelogin" produced an unexpected new value for onelogin_saml_apps.amazon__web__services_aws-1171984, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .rules[2].id: was null, but now cty.NumberIntVal(212595)
- .rules[2].position: was null, but now cty.NumberIntVal(3)
...
Thanks.
any thoughts or updates on this? Thanks.
The issue with the rule switching from "From Existing" to "Map from OneLogin" is a bug. We're working on a solution for this.
With regard to an API endpoint for "Reapply Entitlement Mappings". This is something we have planned but its not under development yet. I suspect it could be a few months before this endpoint is available.
Thanks, @richet . Is the bug you're working on a solution for in this terraform provider, or is it in the onelogin API itself?
I'm wondering if I could try to write a python script using the API to manage my application configuration rules until the terraform provider works for my use case, but don't want to start going down that path if the issue itself is actually internal to the API.
Cheers.
@dlethin Its an issue with the terraform provider. The API does not require any changes at this time.
I'm also running into this exact issue. I modified the provider locally and was able to get the desired behavior of the action showing as "From Existing" instead of "Map from OneLogin" by making the expression
value Optional
instead of Required
and checking for expression
value being an empty string.
App rules resource:
resource "onelogin_app_rules" "shaun-test" {
app_id = onelogin_saml_apps.aws_access_app.id
position = null
enabled = true
match = "all"
name = "shaun-test"
conditions {
operator = "="
source = "email"
value = "<email>"
}
actions {
action = "set_role"
value = [
"<aws-arn1>",
"<aws-arn2>"
]
}
}
The solution was brute force. I'm sure there's a more correct way to handle this.
diff --git a/ol_schema/rules/actions/actions.go b/ol_schema/rules/actions/actions.go
index 5976865..4689c76 100644
--- a/ol_schema/rules/actions/actions.go
+++ b/ol_schema/rules/actions/actions.go
@@ -3,7 +3,7 @@ package appruleactionsschema
import (
"github.com/hashicorp/terraform-plugin-sdk/helper/schema"
"github.com/onelogin/onelogin-go-sdk/pkg/oltypes"
- "github.com/onelogin/onelogin-go-sdk/pkg/services/apps/app_rules"
+ apprules "github.com/onelogin/onelogin-go-sdk/pkg/services/apps/app_rules"
)
// Schema returns a key/value map of the various fields that make up the Actions of a OneLogin Rule.
@@ -15,7 +15,7 @@ func Schema() map[string]*schema.Schema {
},
"expression": &schema.Schema{
Type: schema.TypeString,
- Required: true,
+ Optional: true,
},
"value": &schema.Schema{
Type: schema.TypeList,
@@ -34,7 +34,7 @@ func Inflate(s map[string]interface{}) apprules.AppRuleActions {
if act, notNil := s["action"].(string); notNil {
out.Action = oltypes.String(act)
}
- if exp, notNil := s["expression"].(string); notNil {
+ if exp, notNil := s["expression"].(string); notNil && exp != "" {
out.Expression = oltypes.String(exp)
}
if val, notNil := s["value"].([]interface{}); notNil {
@dcaponi As you appear to be the current maintainer, is this something you can take on or point me in the right direction to fix?
Hi @shaunhellar If this is what it takes to get the provider to work with AWS Multi-Account Apps then its an easy fix. Seems like a misunderstanding on my part of what the required fields were for this.
I can put in the change in about a day or so. You're also welcome to make a pull request to speed up the process 😄
@dcaponi My only concern is if this is a regression: notNil && exp != ""
.
When the resource is configured with no expression on an action (as in my example above) s["expression"].(string)
evaluates to ""
instead of nil
. This causes the provider to include "expression": "",
in the POST which changes the behavior from the intended "From Existing" to "Map from OneLogin". I walked through the code and wasn't able to pinpoint where the nil
was turning into an empty string ""
.
I can't quite tell from the API docs on Create Rule if setting the expression to an empty string ""
is a valid use case and will cause regressions for users of other apps.
@shaunhellar from what I know, yes, setting ""
is a valid use case and omitting the field entirely will clear the expression (making it null essentially) versus having an expression that explicitly checks for ""
Im still tracking down what is causing the flip from from existing
to map from onelogin
as theres no way to set this from the api as far as I can tell.
For now, does it make sense to leave this field as optional so you can omit it and clear the expression but still be able to pass it "" as that is a valid use case?
For now, does it make sense to leave this field as optional so you can omit it and clear the expression but still be able to pass it "" as that is a valid use case?
@dcaponi Yes! I just couldn't get it do that in my local testing :(
For example, using this action block where I haven't set expression
actions {
action = "set_role"
value = [
"<aws-arn1>",
"<aws-arn2>"
]
}
it will still attach expression: ""
in the POST call to the API.
What I'm a bit lost on is why if exp, notNil := s["expression"].(string)
is setting notNil
to true
in this scenario where expression hasn't been set.
@dcaponi Here's a run with the logging set to warn showing the issue. This is with expression
set to Optional
in the schema.
❯ TF_LOG=WARN tf apply
2021/03/01 10:08:08 [WARN] Log levels other than TRACE are currently unreliable, and are supported only for backward compatibility.
Use TF_LOG=TRACE to see Terraform's internal logs.
----
2021/03/01 10:08:08 [WARN] Log levels other than TRACE are currently unreliable, and are supported only for backward compatibility.
Use TF_LOG=TRACE to see Terraform's internal logs.
----
2021-03-01T10:08:09.158-0800 [WARN] plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unimplemented desc = unknown service plugin.GRPCStdio"
2021-03-01T10:08:09.276-0800 [WARN] plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unimplemented desc = unknown service plugin.GRPCStdio"
2021-03-01T10:08:09.406-0800 [WARN] plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unimplemented desc = unknown service plugin.GRPCStdio"
onelogin_saml_apps.aws_access_app: Refreshing state... [id=1368692]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# onelogin_app_rules.shaun-test will be created
+ resource "onelogin_app_rules" "shaun-test" {
+ app_id = "<app id>"
+ enabled = true
+ id = (known after apply)
+ match = "all"
+ name = "shaun-test"
+ position = (known after apply)
+ actions {
+ action = "set_role"
+ value = [
+ "arn:aws:iam::<account>:role/<role1>",
+ "arn:aws:iam::<account>:role/<role2>",
]
}
+ conditions {
+ operator = "="
+ source = "email"
+ value = "shaun.hellar@<company>"
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
2021-03-01T10:08:12.763-0800 [WARN] plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unimplemented desc = unknown service plugin.GRPCStdio"
onelogin_app_rules.shaun-test: Creating...
2021/03/01 10:08:13 [WARN] Provider "onelogin.com/onelogin/onelogin" produced an unexpected new value for onelogin_app_rules.shaun-test, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .actions[0].expression: was null, but now cty.StringVal("")
- .actions[0].value: element 1 has vanished
onelogin_app_rules.shaun-test: Creation complete after 0s [id=279431]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
.actions[0].expression: was null, but now cty.StringVal("") .actions[0].value: element 1 has vanished
This is what's causing the flip in the behavior ^
@shaunhellar just to recap / confirm, you want to do set role in AWS
and specify a handful of ARNs. You try doing this by sending what is effectively the following POST payload:
{
"name": "Rule",
"match": "all",
"enabled": true,
"position": 1,
"conditions": [
{
"source": "email",
"operator": "=",
"value": "shaun.hellar@company.com"
}
],
"actions": [
{
"action": "set_role",
"value": ["some_aws_arn", "another_aws_arn"]
}
]
}
I tried sending this payload to the API direct and it gave me an error that the value is invalid. I suspect the API currently doesn't support your use case here.
I'm working with our API team now to confirm the behavior and see if this is planned or not. Can you confirm too that this is the scenario for which you need support?
@dcaponi Yes, that looks very similar. I just repo'd it via curl
to make sure.
❯ curl 'https://api.us.onelogin.com/api/2/apps/<app_id>/rules' \
-X POST \
-H "Authorization: bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"name": "shaun-test-post",
"match": "all",
"enabled": true,
"position": null,
"conditions": [
{
"source": "email",
"operator": "=",
"value": "shaun.hellar@<company>.com"
}
],
"actions": [
{
"action": "set_role",
"value": [
"arn:aws:iam::<account_id>:role/team-sre",
"arn:aws:iam::<account_id>:role/team-sre-su"
]
}
]
}'
Here's how it showed up in the Admin console UI in my instance of the Amazon Web Services (AWS) Multi Account
app:
Here's a GET
call showing the rule from the API point of view:
❯ curl 'https://api.us.onelogin.com/api/2/apps/<app_id>/rules' \
-X GET \
-H "Authorization: bearer <token>" | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1111 100 1111 0 0 4025 0 --:--:-- --:--:-- --:--:-- 4025
[
...
{
"id": <id>,
"name": "shaun-test-post",
"match": "all",
"enabled": true,
"position": 4,
"conditions": [
{
"source": "email",
"operator": "=",
"value": "shaun.hellar@<company>.com"
}
],
"actions": [
{
"action": "set_role",
"value": [
"arn:aws:iam::<account_id>:role/team-sre",
"arn:aws:iam::<account_id>:role/team-sre-su"
]
}
]
}
The issue in the TF provider is stemming from the fact that it always includes the expression
key even when not set. When I try and create the exact same rule using the following resource definition:
note that expression
is not included in this resource. I've also tried explicitly setting expression: null
with no luck.
resource "onelogin_app_rules" "shaun-tf-test" {
app_id = onelogin_saml_apps.aws_access_app.id
enabled = true
match = "all"
name = "shaun-tf-test"
conditions {
operator = "="
source = "email"
value = "shaun.hellar@<company>.com"
}
actions {
action = "set_role"
value = [
"arn:aws:iam::<account_id>:role/team-sre",
"arn:aws:iam::<account_id>:role/team-sre-su"
]
}
}
I end up with this in the UI:
And when I curl
the API to see this rule you can see the differences from the TF resource definition:
expression
has been erroneously included and has a value of ""
❯ curl 'https://api.us.onelogin.com/api/2/apps/<app_id>/rules' \
-X GET \
-H "Authorization: bearer <token>" | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1378 100 1378 0 0 3827 0 --:--:-- --:--:-- --:--:-- 3827
[
...
{
"id": <id>,
"name": "shaun-tf-test",
"match": "all",
"enabled": true,
"position": 5,
"conditions": [
{
"source": "email",
"operator": "=",
"value": "shaun.hellar@<company>.com"
}
],
"actions": [
{
"action": "set_role",
"value": [
"arn:aws:iam::<account_id>:role/team-sre"
],
"expression": ""
}
]
}
]
I tried sending this payload to the API direct and it gave me an error that the value is invalid. I suspect the API currently doesn't support your use case here.
I just tried sending it bogus values and got a validation error as well. I assume this only works with a correctly setup instance of the Amazon Web Services (AWS) Multi Account
app that has synchronized a list of available roles from the AWS accounts it is linked to.
❯ curl 'https://api.us.onelogin.com/api/2/apps/<app_id>/rules' \
-X POST \
-H "Authorization: bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"name": "shaun-test-post-2",
"match": "all",
"enabled": true,
"position": null,
"conditions": [
{
"source": "email",
"operator": "=",
"value": "shaun.hellar@<company>.com"
}
],
"actions": [
{
"action": "set_role",
"value": [
"arn:aws:iam::<account_id>:role/team-nope",
"arn:aws:iam::<account_id>:role/team-nope-2"
]
}
]
}'
{"code":422,"message":"Validation Failed","errors":[{"field":"actions","message":["Invalid action value(s): arn:aws:iam::<account_id>:role/team-nope, arn:aws:iam::<account_id>:role/team-nope-2"]}]}%
Update: I think I figured out what's going on here. It turns out that when you access data from the Terraform resourceData (via Get
or GetOk
) it gives you whatever the value is as an empty interface. If have the data structured like app_rule
and app_rule.actions[]
things get a little strange.
Asking for the value from app_rule.actions
via the d.Get("actions")
where d is the app_rule as defined in the tf plan file, gets you []interface{}
with any nils
ending up as the zero values when you go to play with them later (in my case the inflate
methods). So that meant that even though nil was being sent for expression
I kept seeing ""
when I go to unpack it.
I discovered after digging through the Terraform code that you can access sub fields by calling them like e, notNil := d.GetOk("actions.2.expression")
(so .
separated strings essentially) for example. And sure enough in this example, notNil
was false when I access sub fields directly and the value e
was indeed <nil>
.
So what I did was move the logic for getting sub-field values out to the top layer where I can call upon the ResourceData
interface to pluck all the sub resources and inflate them separately and not including any fields that were not explicitly set. The caveat so far is that if you now set "expression" = ""
it will be recognized as nil
I think this is something wonky with how terraform handles a zero value situation for strings. It's going to take me a bit to investigate further if this is the correct solution.
There is a PR out from the community https://github.com/onelogin/terraform-provider-onelogin/pull/44 that seeks to address just this problem. I think merging it would be prudent for the time being to solve the immediate problem. If there are no objections, that's what I'll do.
@shaunhellar @dlethin I have released v0.1.14 which contains a temporary workaround so sending no expression should NOT send ""
which causes the flip observed in the UI. I have an issue open with Hashicorp to give a better way to detect this such that the provider can enable nil values, "" values and other values. Detailed explanation is in the comment above.
Please let me know if this helps and I'll close the issue if you're unblocked.
@dcaponi The set_role_from_existing
workaround fixed the issue for me!
Gonna go ahead and close this since its been pretty quiet since my last comment. If this is still a blocker, feel free to reopen.
I went MIA for a while after reporting this issue, as we ended up implementing our automation in a python script using the onelogin API to unblock us. We're circling back to our internal project and have the chance to reconsider using this terraform provider. Appreciate the work @dcaponi and @shaunhellar pushing this forward. Hopefully within the next few weeks I'll give this a try. Cheers.
Actually I gave this a whirl quickly and unfortunately didn't have any luck. Here's my terraform version info:
terraform version
Terraform v0.15.3
on darwin_amd64
+ provider registry.terraform.io/onelogin/onelogin v0.1.14
Here's my resource configuration:
resource "onelogin_app_rules" "example" {
app_id = [REDACTED]
position = 10
enabled = true
match = "all"
name = "terraform-test"
conditions {
operator = "="
source = "email"
value = "[REDACTED]"
}
actions {
action = "set_role_from_existing"
value = [
"arn:aws:iam::[REDACTED]:role/[REDACTED]",
]
}
}
Here is the output of the apply showing the error I'm getting:
✗ terraform apply
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# onelogin_app_rules.example will be created
+ resource "onelogin_app_rules" "example" {
+ app_id = "[REDACTED]"
+ enabled = true
+ id = (known after apply)
+ match = "all"
+ name = "terraform-test"
+ position = 10
+ actions {
+ action = "set_role_from_existing"
+ value = [
+ "arn:aws:iam::[REDACTED]:role/[REDACTED]",
]
}
+ conditions {
+ operator = "="
+ source = "email"
+ value = "[REDACTED]"
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
onelogin_app_rules.example: Creating...
╷
│ Error: error: context: [ol http service], error_message: [{"code":422,"message":"Validation Failed","errors":[{"field":"actions","message":["Invalid action value(s): arn:aws:iam::[REDACTED]:role/[REDACTED]"]}]}]
│
│ with onelogin_app_rules.example,
│ on onelogin.tf line 23, in resource "onelogin_app_rules" "example":
│ 23: resource "onelogin_app_rules" "example" {
│
╵
Not immediately sure why its failing. As far as I know the role exists. If I manually add that rule via the UI I can reference that role.
Any thoughts on what's going on here? Thanks.
I tried the above on the latest provider release and still had the same problem.
[this is an issue we had reported through another channel and wanted to capture it as a github isssue for better trackability]
We manually configured and got working through the UI the "AWS Multi-account applications" app following the instructions outlined here -- https://onelogin.service-now.com/kb_view.do?sysparm_article=KB0010344
I then did the following:
onelogin terraform-import
to start managing this app in terraform.terraform plan
to validate the project resolves cleanlyterraform plan
to validate the plan would delete only that rule we no longer want"Your request included an invalid SAML response. To logout, click here"
In troubleshooting this, I clicked on the first rule in my applications configuration and I can see that my rule configuration changed.
What used to look like this:
ended up looking like this:
It seems the actions got all messed up, switching from "from existing" over to "map from onelogin"
Once I manually reconfigured the rule back to what is was originally and re-ran "reapply entitlement mappings", the application started working again.
Is there some configuration application configuration not currently supported by this provider or exposed by the underlying API endpoint its calling?
Also, as a secondary question is the "reapply entitlement mappings" functionality exposed via the onelogin API? Assuming we can get the problem identified in this issue working, Ideally we would like to trigger a call to programmatically reapply the mappings if the rules change -- probably through a local provisioner inside a terraform null_resource.
Thanks.
Doug