roleARN for AWS SAML_2.0 application via API


I am creating app in Okta via API. App is in AWS and it is SAML_2.0 app, everything works fine the only thing - I see that roleARN is not being assinged to newly created app. Wondering what is wrong with my manifest and actually wasn’t able to find any reference to how to do so in:

Herer is my app.json (I thought that setting it in is the right way):

  "label": "AppName",
  "accessibility": {
    "selfService": false,
    "errorRedirectUrl": null,
    "loginRedirectUrl": null
  "visibility": {
    "autoSubmitToolbar": false,
    "hide": {
      "iOS": false,
      "web": false
    "appLinks": {
      "login": true
  "features": [],
  "signOnMode": "SAML_2_0",
  "credentials": {
    "userNameTemplate": {
      "template": "${fn:substringBefore(source.login, \"@\")}",
      "type": "BUILT_IN"
    "signing": {}
  "settings": {
    "signOn": {
      "defaultRelayState": "",
      "ssoAcsUrl": "https://appURL",
      "idpIssuer": "https://oktaEndpoint/${org.externalKey}",
      "audience": "https://oktaEndpoint",
      "recipient": "https://oktaEndpoint",
      "destination": "https://oktaEndpoint",
      "subjectNameIdTemplate": "${user.userName}",
      "subjectNameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
      "responseSigned": true,
      "assertionSigned": true,
      "signatureAlgorithm": "RSA_SHA256",
      "digestAlgorithm": "SHA256",
      "honorForceAuthn": true,
      "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
      "spIssuer": null,
      "requestCompressed": false,
      "allowMultipleAcsEndpoints": true,
      "acsEndpoints": [
          "url": "https://oktaEndpoint",
      "attributeStatements": [
          "type": "EXPRESSION",
          "name": "Attribute",
          "namespace": "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified",
          "values": [
    "app": {
      "roleARN": "arn::appRoleARN",
      "sessionDuration": "43200",
      "orgName": "${yourOktaDomain}",
      "url": "https://oktaEndpoint"
    "notifications": {
      "vpn": {
        "network": {
          "connection": "DISABLED"
        "message": null,
        "helpUrl": null

Would appreciate any response.

PS: this is an Amazon Appstream 2.0 app btw and when we add via UI we use Amazon Appstream 2.0 application type

If you check the app after its created in your Okta org, do you see anything come back in that object?

That particular part of the application model only applies to OIN applications, so I don’t think creating a custom SAML app with values in this object will work as you expect it to.

just checked it and its not there. So you mean it is expected that I don’t see roles in section for custom SAML app @andrea ? Is there any documentation on it? Because currently my concern is - I compare things created manually via UI and things created with API, see that they are different and not quite sure if it is fine or it is broken.

That’s correct, these properties are not part of a custom application model (we do not document the app object as part of the settings in our API docs), only OIN applications have properties within

Are you saying that a custom SAML app created via the UI is different than one created via API? What’s different about them?

So the situation is following - I have Appstream 2.0 applications which were previously created manually via UI, now I am automating the process and crating them with API, because there is no such type as “Appstream 2.0 application” for API calls, I am using custom SAML 2.0
So far that is the only difference I’vememge to notice, but not sure if it’s the only one

Was the one created in the UI also a custom SAML app (Create New App → SAML 2.0) or did it come from the app catalog (OIN)?

the one created with UI was “Appstream 2.0” app from OIN

Then that’ll be why it looks different.

Unfortunately, it doesn’t look like we support adding OIN integrations via API calls at this time. I found the following feature request in our Ideas portal requesting this: Idea #129355

Got it. Thank you @andrea! So what exactly is that parameter and what are implication of it’s missing in SAML 2.0 cusotm app?

Looks like Appstream must use that for their OIN integration, but I don’t know the specifics about how it works. My guess would be we send that value back to them during the SAML assertion, but I’m not positive.

You can try to see if they offer any advice about manually integrating with them with SAML, though it likely has more steps then using the existing OIN integration.