Single Sign-on

Software AG Cloud supports SSO that allows users to authenticate themselves against an Identity Provider (IdP) rather than obtaining and using a separate username and password. Once the IdP authenticates the user­­­­­­s, it informs Software AG Cloud about it, which in turn lets the users access the applications without having to sign in using their Software AG Cloud credentials. This makes the login process easier, faster, and more secure for users.

In this tutorial, you will learn how to configure OKTA as an Identity Provider to authenticate Software AG Cloud users.


To set up SSO for Software AG Cloud, ensure that you have:

  • Access to your identity provider’s configuration settings
  • Cloud-Tenant-Administrator role privileges in Software AG Cloud

Overview of Steps

Step 1: Create the URI for connecting IdPs to Software AG Cloud

Step 2: Setup the Software AG Cloud application in the IdP

Step 3: Import IdPs SAML settings into Software AG Cloud

Step 4: Configure IdP details in Software AG Cloud

Detailed Steps

Step 1: Create the URI for connecting IdPs to Software AG Cloud

Log in to your Software AG Cloud account. Navigate to My Cloud > Administration page, and click the Single sign-on tab.


Click Add Identity Provider. A new screen appears where you add an Identity Provider to authenticate Software AG Cloud users.


Enter the following details in the Add Identity Provider screen:

Identity provider display name: Enter a friendly name for the Identity Provider, for example, IDP_SAG_Test.

Identity provider unique identifier for use in Software AG Cloud redirect URI: Enter a display name for the Identity Provider.

Software AG Cloud redirect URI: Copy the auto-created URI that appears in the Software AG Cloud redirect URI field to the clipboard. Use the icon at the far right of the field to copy the URI.

Note: Keep this window open, as you will need these details for setting up the Software AG Cloud application in your IdP in the next step.

Step 2: Configure IdPs (OKTA) to connect to Software AG Cloud

Log in to your IdP account as a user with Administrator privileges.


Go to the Admin > Applications to create a new application integration. Click the Add Application button to add the Software AG Cloud application.


Select SAML 2.0 as the sign-on method.


In the APP name field, enter an application name. After this, click Next.


In the Configure SAML settings tab, enter the following details:


Single Sign-on URL: Paste the copied URI here. Select the checkbox to specify the URI in both the recipient and the destination URL. Also, paste the copied URI into the Audience URI field and Default RelayState.

Note: The name of this field may be different in some IdPs. For example, ‘SP Entity ID’, ‘Audience URI’.

NameID Format: Specify OKTA properties to pass to Software AG Cloud. OKTA must pass the Name ID format property to Software AG Cloud. Set the value for this field to ‘EmailAddress’. Other OKTA properties are optional.

Note: The email address, first name, and last name attributes appear on the OKTA user interface by default, and OKTA must pass these attributes to Software AG Cloud. Other OKTA user attributes are optional.

In the Attribute Statements section, you provide attribute names for all required and optional attributes to pass to Software AG Cloud; these names will appear with their values in the Software AG Cloud user profiles. Ensure that you note the attribute names for use in a later step.


If you are going to assign Software AG Cloud roles to OKTA user based on OKTA group membership, go to the Group Attributes section, enter roles as the name of a group attribute, and specify a filter that matches the names of the OKTA groups you created, for example, SAG_Cloud.


Note: If you are going to assign Software AG Cloud roles to OKTA users, and you therefore created OKTA groups for the Software AG Cloud roles, you assign users to the application by assigning the groups to the application. If you did not create OKTA groups, assign users to the application individually.

After configuring SAML settings, click Next to proceed to the Feedback section. For this tutorial, we configure the following details:


Once you have configured the Feedback options, click Finish.

Step 3: Import IdP SAML settings into Software AG Cloud

To import the SAML settings of IdP into Software AG Cloud:

Go to the newly created OKTA application, click Sign On, click Identity provider metadata link, and then either copy the URI or save the metadata to file.

Step 4: Configure IdP details in Software AG Cloud

Now switch back to the My Cloud SSO Settings window and complete the configuration in Software AG Cloud.

If you copied the OKTA metadata URI or saved the metadata to file, choose to import, and then specify the URI or file. 

Click Next.


On the Configuration page, complete the fields as necessary.


Note: If you imported the OKTA metadata, some of the fields are pre-populated with that metadata.

If you did not import the OKTA metadata, the Software AG Cloud fields map to OKTA fields as follows. Let’s understand what these fields are:

  • SAML basic settings

      Single sign-on service URL: This is the unique identifier of the Identity  Provider. This field is pre-populated.

      - NameID policy format: This is the format to use for the subjects of SAML assertions. This field is pre-populated.

  • SAML advanced settings

         - HTTP-POST binding response: This attribute indicates whether the identity provider will use HTTP-POST binding to respond to authentication requests instead of the default HTTP-Request rebinding. This attribute is turned on.

        - HTTP-POST binding for AuthnRequest: This attribute indicates whether the identity provider expects applications to use HTTP-POST binding to submit authentication requests instead of the default HTTP-Redirect binding. This attribute by default is turned on.

         - Assertions signed (on/ off): Here if the "Assertions Signed" attribute is turned ON in My Cloud, then the "assertion signature" attribute of IdP should be "Sign SAML assertion”.

          - Assertions encrypted: This attribute indicates whether the service provider expects an encrypted assertion from the identity provider. If this property is turned on, then the “Assertion HTTP-POST binding response Encryption” attributes needs to be turned on in the identity provider and additionally, the encryption certificate needs to be uploaded to the identity provider.

           - Validate signature: This attribute indicates whether Software AG Cloud will validate SAML assertion signatures. If “Validate Signature” is turned on, you need the public certificate from the Identity Provider to be copied to  the “Validating X509 Certificates” field in My Cloud.

          • Attributes:

           Here you map the Identity provider user attributes to the  Software AG Cloud user attributes.


          Username: This always defaults to the value set for NameID attribute.

          Work email - email

          First name - firstName

          Last name - lastName

          • Roles

          On the Roles page, you grant access to IdP users as follows by assigning default Software AG Cloud roles to OKTA users or by assigning Software AG Cloud roles to OKTA users based on OKTA group membership.

          For the second case, click Assign Software AG Roles to users by mapping to identity provider roles. Click +, select a Software AG Cloud role and then type the name of the OKTA group that corresponds to the role.

          Note: You can later go to individual Software AG Cloud products and modify access.

          Software AG Cloud Role: The attribute name must be set as "roles" and the value should be the names of the groups.

          Save the Identity Provider configuration. Now the configuration for Identity Provider in Software AG Cloud is complete.

          On the successful configuration of Identity Provider, you will see the Identity Provider name on the Software AG Cloud login page.


          Upon successful authentication by the SSO server, you are redirected to Integration and able to access integration without requiring additional authentication.