Welcome to our docs site. Docs on this site are for ACP version 9.
See these links for previous versions: Version 8, Version 7

Service Authentication

From the Security>Service Authentication page in the SOC, you are able to configure security options for service authentication your Platform.

Platform-Level External Authentication

Platform Operators can implement a customized plugin that allows for External Authentication via HTTP header(s) for both .NET and Java applications. Because it must specify exactly how the Platform will communicate with the external authentication API that you will use, you must create and customize the plugin for your Organization’s use case. For assistance creating an External Authentication plugin, please contact your support representative.

Once you have created an External Authentication plugin, you can upload the plugin from this section of the page.

Click on the Enable External Authentication button, to open the External Authentication Plug-in: Upload Package dialog.

To upload your plugin,

  • fill in a comma-separated list of HTTP-HEADERS to provide to the plugin
  • click on the Choose File button to browse and select your External Authentication plugin. Once the HTTP headers and plugin selection are set

Click Upload to complete your External Authentication configuration (or click Cancel button if you are not ready to complete the configuration).

Once External Authentication has been successfully configured, the Security page will display controls to Update External Authentication using an updated plugin or to Disable External Authentication.

As needed you can update the HTTP headers through the Authentication.ExternalProvider.Headers Platform Registry Setting. Additionally, you can configure the expiration for inactive sessions established through Platform-Level External Authentication by chnaging the Authentication.ExternalProvider.SessionCacheDurationInMinutes registry setting.

Defining Linux User Accounts

If you’re hosting Linux workloads on your Platform (e.g. Java, Python, Go, etc.), you can define runtime accounts Developers can assign to their guest applications’ components. If set for an application component, that account is used as the runtime account for individual deployed instances of that component on the server(s) they deploy to.

Depending on Platform configuration, Apprenda may attempt to auto-create specified account on the Linux server chosen as the deployment host for its application instance, or it may just check that the account already exists before deploying (and deployment will fail if the account doesn’t exist).

To add an allowed account to the list, click the Add Account button and

  1. fill in the Username of the account to be added
  2. fill in the Token to associate with the account. Read more about user account tokens

Click save (or cancel to not add the account).

User Account Tokens

No password is required to create and use the account as a runtime account on your Platform’s Linux servers. Instead, the Platform requires a token be set for each user account.

The token you assign when adding the account on the Platform provides an added layer of security when Developers assign the account to an application component. When Developers attempt to set one of the accounts on this list as a runtime account, the Platform will prompt them to enter the associated token. The Platform will not let Developers use an account if the Developer does not enter the correct token. Using tokens enables you to control which Development Teams have access to which application runtime accounts, by giving you control over who has access to the account tokens.