From the Configuration>Security page in the SOC, you are able to configure security options for your Platform.
If Identity Federation is enabled on your Platform, use this section to determine whether authentication occurs on a Platform level (all users authenticate against a single user system) or account level (each Tenant/Organization account uses a different user system for authentication). Note that you cannot enable account-level Federation if any Platform Users belong to more than one Development Team/Tenant Account.
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 at firstname.lastname@example.org.
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,
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.
You can enable SSL settings for your Platform during installation, or, once the Platform is running, you can modify Platform-wide SSL Enforcement from this section of the Security page.
Enable or Disable SSL Enforcement by clicking the button in this section.
When SSL Enforcement is enabled, all future traffic (including that for all guest applications) on HTTP is automatically re-directed to HTTPS, so there is no Tenant disruption – even if the User is already logged in to the Platform. While enabling SSL Enforcement requires all User traffic to be re-directed to HTTPS, disabling SSL enforcement does not disable HTTPS or require all User traffic to be re-directed to HTTP. This means that the Tenants may always use SSL to access their guest applications even if it is not required. It also means that applications where SSL is enforced on a per-application basis (as configured through the Developer Portal) or through the Apprenda Applications setting below will use SSL even if Platform-wide Enforcement is disabled.
You can enable or disable SSL Enforcement for only Apprenda applications in this section. When enabled, SSL will be enforced for all Apprenda Applications, including the SOC.
If Platform-wide SSL Enforcement is enabled, all traffic for Apprenda applications will be re-directed to HTTPS regardless of whether or not the SSL Enforcement for Apprenda Apps settings is enabled. See a list of Apprenda applications on the Applications page by searching for the term “Apprenda”.
You can enable SSL settings for your Platform during installation, or, once the Platform is running, you can update the SSL certificate used for each cloud in this section of the Security page.
Click Upload Certificate or Repair your HTTPS Bindings when you are finished. Read more about on TLS/SSL certificates on your Platform.
If you’re hosting Linux workloads on your Platform (e.g. Java, Python, Go, etc.), you can define runtime accounts Develoeprs 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
Click save (or cancel to not add the account).
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.