Chatta subito con l'assistenza
Chat con il supporto

Cloud Access Manager 8.1.4 - Configuration Guide

Configuring a front-end authentication method Adding a web application Configuring step-up authentication Managing your SSL certificate Changing the Cloud Access Manager service account password Reporting Customizing One Identity Cloud Access Manager

Exporting an application configuration template

When you have configured an application, you can export the configuration as a template file that can be imported into other Cloud Access Manager installations and used to re-create your configured application.

To export an application configuration as a template, in the list of applications click the download icon next to the application you want to export.

Before you can create a template, you need to know whether there are any environment or account specific variables within your application configuration. For example, any applications that have been purchased and installed on your local network are highly likely to have environment specific URLs within the configuration.

For SaaS applications such as Salesforce.com there may also be account specific variables within URLs, such as a unique domain name or account identifier.

To setup applications with no environment or account specific variables

If there are no environment or account specific variables in the application’s configuration, you can:

  1. Enter the template name.
  2. Clear the box shown in the image below:

  3. Click Create Template.
  4. When prompted to save or open the file, select Save.

To setup applications with existing environment or account specific variables

If there are environment or account specific variables within the application’s configuration, you need to define the template settings page.

The template settings page is the first page of the application setup wizard that you will see when you click on a template. The image below shows an example of the Salesforce template settings page within Cloud Access Manager.

The text box in the image above is referred to in the Export Application as Template page as the Input Field. The value entered into this field by the administrator using the template is referred to as the Input Field Value. The Template settings page instructions should outline what the administrator must enter into the Input Field.

In the Salesforce example, this instruction is displayed below the Settings for Salesforce heading. The Input Field Label is used to identify the Input Field text box and is displayed just above the input field text box. The Format of Input Field Value list allows you to select the required format of the Input Field Value. For example, on the Salesforce template settings page, the Input Field Value must be a valid URL, so the format of the Input Field Value would be set to Full URL.

The final step is to identify the part of the application you are currently exporting as a template which is unique to your environment/account. For example, when configuring Google Apps the recipient field will be in the format https://www.google.com/a/yourgoogledomain.com/acs where yourgoogledomain.com is an account specific domain.

In this example you would enter yourgoogledomain.com into the Environment/account specific value to be replaced text box. This text will be replaced by the value users enter into the input field when using the template.

Example application configuration template

In the following example configuration for Google Apps, the Input Field Value would be questapitest.com as this is an account specific variable. The text in italics is the value of each field in your application’s configuration. So, to make the Recipient field generic you need to tell Cloud Access Manager where the Input Field Value would be. The Audience / SP Identity field does not contain questapitest.com, so we can select that option.

When you have configured all fields, click Create Template. You are prompted to save or open the file. Select Save. The application configuration template file is now ready to use.

Forwarding claims to federated applications

Applications using SAML 2.0, WS-Federation or OpenID Connect/OAuth 2.0 to perform single sign-on (SSO) may receive claims from Cloud Access Manager, which are then delivered to the application as part of the assertion which tells the application the user has successfully authenticated. A claim is a piece of information about a user, which the application can use to tailor its interface or to make authorization decisions.

To configure Cloud Access Manager to send claims to the application, you must choose a name for each claim, and then map that name to an information source.

Cloud Access Manager can be configured to:

  • Forward claims authored by the front-end authenticator which authenticated the user.
  • Send static claims.
  • Send the names of the user's Cloud Access Manager roles as claims.

These configuration options can be used individually or in any combination. Additionally, you can make the transmission of a claim dependent on a user's role membership.

To configure an application to receive claims from Cloud Access Manager

NOTE: You cannot configure claim mappings when you create the application definition. The facility to configure claim mappings is only available in edit mode, after you have created the application definition.

  1. From the Cloud Access Manager Administration Menu, under Applications, click View and Edit.
  2. Click the edit icon next to the application you want to send claims to.
  3. In the navigation bar, click Claim Mapping.
  4. To add a new claim mapping, click the add icon in the top right hand corner of the claim list pane.
  5. Complete the Name of the claim to send to the application. For OpenID Connect/OAuth 2.0 applications, you can select from a preset list of standard claims.
  6. Rule Processing Mode: Mapping rules can be applied to users who have a certain role. You can use the Rules Processing Mode setting to determine whether only the first rule matching the user(s) should apply, or whether all rules should apply.

    • Use first rule matched - return the result of the first rule where the user is a member of the role set on the rule.
    • Use all rules matched - return the results of all rules where the user is a member of the role set on the rule.
  7. In the Claim Rule box:

    1. Select the roles that you want to apply the rule to.
    2. Choose the Claim mapping mode:

      • If you want the claim to be derived from a claim from an identity provider, choose Map claim to user attribute.
      • If you want Cloud Access Manager to set the claim to a constant value, choose Map claim to static value.
  8. If you have chosen Map claim to static value, enter that value in the box provided. If you have chosen Map claim to user attribute, choose the attribute holding the information you want to send as a claim from the dropdown. To add more attributes to the list displayed in the dropdown, click Manage User Attributes.

  9. If the same claim can be derived from different attributes depending on the user's role, you can add another Claim Rule by clicking the Add New Claim Rule button. If you have defined multiple Claim Rules you can order them by dragging and dropping the rules into the correct position, so that the correct rule is processed for users in a given role.
  10. If you want to configure Cloud Access Manager to send more claims, click the add icon in the top right hand corner of the claim list pane.
  11. You can send the names of the user's Cloud Access Manager roles to the application as claims. To do this, select the Send Cloud Access Manager role claim box at the bottom of the claim list panel.

NOTE: If you select Group Memberships for a claim rule and you are using Active Directory the user's Primary Group is not returned. In default installations, the user's Primary Group is Domain Users. The Primary Group is not returned because the claim rule returns the values in the memberOf attribute and the Primary Group is determined using the primaryGroupID attribute.

Adding HTTP headers to proxy applications

If you are using Cloud Access Manager to proxy an application and authenticate users to that application you have the option of configuring HTTP headers to be sent as part of the authentication. The following type of applications can be configured to send extra HTTP headers:

  • Form Fill
  • Integrated Windows Authentication
  • HTTP Basic Authentication
  • HTTP Header.

Headers are pieces of information about a user, which the application can use to tailor its interface or to make authorization decisions. The mechanism for configuring additional HTTP headers uses the same process of building information from claim rules that is used in claim mapping. For detailed instructions on how the mapping interface works please refer to Forwarding claims to federated applications, where you see Claim Mapping replace this with Header Mapping.

To configure an application to receive claims from Cloud Access Manager

NOTE: You cannot configure header mappings when creating the application definition. The facility to configure header mappings is only available in edit mode, after the application definition has been created.
  1. From the Cloud Access Manager Administration Menu, under Applications, click on View and Edit.
  2. Click on the edit icon next to the application you want to send claims to.
  3. In the navigation bar, click Header Mapping.
  4. Follow the instructions in Forwarding claims to federated applications, where you see Claim Mapping replace this with Header Mapping.

Configuring step-up authentication

Topics:

When you configure an Active Directory or Lightweight Directory Access Protocol (LDAP) front-end authenticator you can also configure two-factor authentication. Configuring a front-end authentication method describes how to configure two-factor authentication for all users, for all applications.

This section describes how to modify the configuration in two ways:

  • Users are only prompted for two-factor authentication for some applications. This is known as step-up authentication as users will only be prompted for two-factor authentication when required.
  • Only external users are prompted for two-factor authentication.
Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione