[BUG] Cannot define enrichment attributes if the CorpProvider is OIDC type

[ptesny]

Is there an existing issue for this?

• I have searched the existing issues

What version of the Terraform provider are you using?

0.3.0-beta1

What version of the Terraform CLI are you using?

1.14.0

What type of issue are you facing

bug report

Describe the bug

It seems there is now way to define the enrichment attributes when creating an OIDC corporate identity provider.
These attributes would available for SAML corporate identity provider but cannot be set with the OIDC corporate identity provider.
Or, at least I have not found a way to get it done by the provider

Expected Behavior

To be able to define the enrichment attributes regardless of the type of the corp provider

Steps To Reproduce

The below code snippet works nicely but the enrichment attributes that I still need to set manually in the aftermath.

You will notice a hack with the client_secret.
The SCI TF provider will not accept an empty secret even if the secret is not required by the IDP provider being federated

#### github.com corporate idp


locals {
  GITHUB_IDP_NAME = "GITHUB"
  GITHUB_IDP_ISSUER = "https://token.actions.githubusercontent.com"
}

/**/
resource "sci_corporate_idp" "github_idp" {

  display_name = "${local.GITHUB_IDP_NAME}"
  forward_all_sso_requests = false

  identity_federation = {
    allow_local_users_only = true
    apply_local_idp_auth_and_checks = false
    required_groups = [ "GitHub"] 
    use_local_user_store = true
  }
  login_hint_config = {
    login_hint_type = "userInput"
    send_method = "urlParam"
  }

  name = "${local.GITHUB_IDP_NAME}"
//  assertion_attributes = [
//      {
//          name  =  "NameID",
//          value = "<foo.bar>@github.com"
//      }
//  ]

  oidc_config = {
    additional_config = {
      disable_logout_id_token_hint = false
      enforce_issuer_check = false
      enforce_nonce = false
    }

    client_id = "${local.GITHUB_IDP_NAME}"
    client_secret = "secret not required"

    discovery_url = "${local.GITHUB_IDP_ISSUER}"    
    subject_name_identifier = "email"

    enable_pkce = false
    scopes = [
      "openid"
    ]    
  }

  type = "openIdConnect"

  lifecycle {
    ignore_changes = all
  } 

}


output "github_idp" {
  value = sci_corporate_idp.github_idp
}
/**/

Add screenshots to help explain your problem

No response

Additional context

No response

[diya-dhan]

Hi @ptesny

With respect to the enrichment attributes, the API supports the parameter assertionAttributes which falls under the parent attribute saml2Configuration. After some testing, I believe its safe to conclude that the same API parameter is used for enrichment attributes for both SAML and OIDC configurations.

For instance:

Here is a sample SAML2 Corporate IDP, whose Enriched Assertion Attributes are as follows:

A get call on the same IDP returns the response as expected, with the parametersassertionAttributes populated:

Here is a sample OIDC Coporate IDP, whose Enriched Token Claims are as follows:

A get call on the same returns a response with the above mentioned parameter populated:

The following API request could be used as a workaround:

{
    "displayName" : "openid-test",
    "name" : "openid-test",
    "type" : "openIdConnect",
    "saml2Configuration": {
            "assertionAttributes" : [
               {
                  "name" : "name",
                  "value" : "value"
               }
            ]
     },
    "oidcConfiguration": {
         "discoveryUrl" : "https://accounts.sap.com",
         "clientId" : "abc",
        "tokenEndpointAuthMethod": "privateKeyJwt"
    }
 }

This will create an OIDC configured coporate IDP with the Enriched Tokens :)

But this something that the provider cannot handle as we have a check in place that validates the configuration provided along with its type. i.e., providing a SAML configuration for type openIdConnect will not be possible through the provider.

Hence the only workaround for the time being is manually configuring these parameters. We will reach out the API team w.r.t the gap identified and address the issue furthur.

Additionally, the requirement of the parameter client_secret is in accordance with the value of tokenEndpointAuthMethod. If the authentication method is not specified, the API throws the following error:
"message": "Missing mandatory attribute \"clientSecret\" for OIDC configuration."
as the default auth method is client secret based. In scenarios when the jwt methods are utilised, the client secret need not be defined.

[ptesny]

Hi @diya-dhan

FYI: Again one can use PATCH syntax to help go around the current SCI TF provider behaviour and amend the enrichment data after having the corp idp resource created...

{
  "operations": [
    {
      "op": "add",
      "path": "/saml2Configuration/assertionAttributes/0",
      "value": {
        "name": "NameID",
        "value": "${GithubRepositoryUserId}"
      }
    }
  ]
}

[ptesny]

@diya-dhan

Additionally, the requirement of the parameter client_secret is in accordance with the value of tokenEndpointAuthMethod. If the authentication method is not specified, the API throws the following error:
"message": "Missing mandatory attribute "clientSecret" for OIDC configuration."
as the default auth method is client secret based. In scenarios when the jwt methods are utilised, the client secret need not be defined.

what is missing is that no secret may be needed either with non-web SSO corp idps, so-called headless idps suitable for OIDC authentication in CI/CD pipelines.

The logic behind is that if there is no authorization code flow available than this is an IDP-delegated provider.

This is nicely covered by SAP IAS itself when doing this manually, for instance:

The metadata from the corporate identity provider doesn't include the authentication endpoints for interactive login. The corporate identity provider can't participate in browser-based SSO flows.

[diya-dhan]

what is missing is that no secret may be needed either with non-web SSO corp idps, so-called headless idps suitable for OIDC authentication in CI/CD pipelines.

By any chance have you configured the same via the API? I run into the same error as mentioned before.

I believe this is because via the UI, the Discovery URL is validated with Load button which isn't handled by the API. Have you been able to achieve the same with the POST call?

[ptesny]

@diya-dhan I did it with SCI TF provider by simply adding a dummy secret as client_secret = "secret not required"

locals {
  GITHUB_IDP_NAME = "GITHUB"
  GITHUB_IDP_ISSUER = "https://token.actions.githubusercontent.com"
  GithubRepositoryUserId = "<GithubRepositoryUserId>"

  GITHUB_PROVIDERS = {
    GITHUB = {
      GITHUB_IDP_NAME        = "GITHUB"
      GITHUB_IDP_ISSUER      = "https://token.actions.githubusercontent.com"
      GithubRepositoryUserId = "GithubRepositoryUserId_01"
    },
    GITHUB_TOOLS = {
      GITHUB_IDP_NAME        = "GITHUB_TOOLS"
      GITHUB_IDP_ISSUER      = "https://github.tools.sap/_services/token"
      GithubRepositoryUserId = "GithubRepositoryUserId_02"
    }
  }

}

resource "sci_corporate_idp" "github_idp" {
  
  for_each = local.GITHUB_PROVIDERS

  display_name = "${each.value.GITHUB_IDP_NAME}"
  forward_all_sso_requests = false

  identity_federation = {
    allow_local_users_only = true
    apply_local_idp_auth_and_checks = false
    required_groups = [ "GitHub"] 
    use_local_user_store = true
  }
  login_hint_config = {
    login_hint_type = "userInput"
    send_method = "urlParam"
  }

  name = "${each.value.GITHUB_IDP_NAME}"
//  assertion_attributes = [
//      {
//          name  =  "NameID",
//          value =  local.GithubRepositoryUserId
//      }
//  ]

  oidc_config = {
    additional_config = {
      disable_logout_id_token_hint = false
      enforce_issuer_check = false
      enforce_nonce = false
    }

    client_id = "${each.value.GITHUB_IDP_NAME}"
    client_secret = "secret not required"

    discovery_url = "${each.value.GITHUB_IDP_ISSUER}"    
    subject_name_identifier = "email"

    enable_pkce = false
    scopes = [
      "openid"
    ]    
  }

  type = "openIdConnect"
}