In most situations the WS-Federation token produced by Cloud Access Manager, in response to an authentication request is accepted by the service provider. However, if a service provider has special requirements for the way the token is configured, then you can modify the token options on the WS-Fed Token Settings tab for the application.
Any settings changed on this page will only affect the selected application.
|
NOTE: To change the setting for all WS-Federation applications, follow these steps:
|
For a description of the available configuration options, please refer to the table below.
|
NOTE: The settings for an individual application take precedence over global settings. |
Name | Description | Default |
---|---|---|
wsfedtoken.minutes_before |
The number of minutes before the token IssueInstant to set the NotBefore attribute in the Conditions element. |
0 minutes |
wsfedtoken.minutes_after |
The number of minutes after the token IssueInstant to set the NotOnOrAfter attribute in the Conditions element. |
30 minutes |
wsfedtoken.name_id |
The value of the Format attribute of the NameIdentifier element in the Subject. |
urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified |
wsfedtoken.logout_request_binding |
If HttpRedirect is selected then logout requests will be sent to the application. If Disabled is selected then logout requests will not be sent. |
HttpRedirect |
For information on how to use Cloud Access Manager as an OAuth v2.0 or OpenID Authorization Server, please refer to the document entitled One Identity Cloud Access Manager How To Develop OpenID Connect Apps.
If the application you are configuring does not provide a user provisioning API, you can use Cloud Access Manager as an intermediary between the user and the manual process of creating a user account for the application.
Manual user provisioning enables users to request a user account for an application from their application catalog. Cloud Access Manager then sends an email to the owner of the application advising them that the user requires an account.
The application owner manually creates the user account within the target application. When the user account has been created, the application owner returns to the email received from Cloud Access Manager and clicks the confirmation link contained in the email to confirm that they have created the user account.
Alternatively, a Cloud Access Manager administrator can view any outstanding manual provisioning requests. To do this, go to Cloud Access Manager Application Portal | Users |Manual Provisioning Requests and confirm that the requests have been dealt with.
When the user account request is confirmed as complete, the application is displayed on the user’s application portal home page within Cloud Access Manager.
|
NOTE: You must have SMTP settings configured within Cloud Access Manager to enable manual user provisioning. |
To configure HTTP Basic Authentication
Log in to the Administration Console using the desktop shortcut Cloud Access Manager Application Portal and select Add New from the Applications section on the home page.
Cloud Access Manager provides a set of application templates to automatically configure common applications. This example describes how to configure an application manually, rather than using a template.
Select HTTP Basic Authentication and click Next.
|
NOTE: Additional user attributes can be sent in HTTP headers. In this example we want to send the username and password only. |
Enter the protocol and Fully Qualified Domain Name (FQDN) used by the application you wish to Single Sign-On (SSO). Click Next.
|
NOTE: The protocol and FQDN can be obtained from the URL used to access the application. For example, if the application is normally accessed using https://ars.democorp.local/ARServerAdmin, the protocol would be Secure HTTP (HTTPS) and the FQDN would be ars.democorp.local |
In this step, Cloud Access Manager needs to know how to proxy the application. Typically this involves configuring Cloud Access Manager to proxy the entire web server used by the application using a new fully qualified domain name (FQDN). This is the preferred method and the method compatible with the most applications. To configure Cloud Access Manager in this way, simply enter a new public FQDN into the field provided on the Proxy URL page, and click Next.
The new FQDN should be within the wildcard DNS subdomain created during the installation, which will resolve to the public IP address used by the proxy. For example, if you created the wildcard Domain Name Service (DNS) subdomain *.webapps.democorp.com during the installation you could use the FQDN owa.webapps.democorp.com to proxy Microsoft Outlook Web App. If you did not create a wildcard DNS subdomain for Cloud Access Manager during the installation you will need to manually add this new FQDN into your public DNS. The new FQDN should be covered by the wildcard SSL certificate you are using.
Alternatively, some applications are installed entirely within their own virtual directory on the web server where they reside. One example of such an application is One Identity Active Roles which installs into the virtual directory /ARServerAdmin. In this case you may be able to configure Cloud Access Manager to proxy the application's virtual directory only, rather than the whole web server, and reuse the FQDN of the proxy. To configure this option, select the proxy's FQDN from the list, then enter the virtual directory where the application is installed into the field below and click Next.
|
NOTE: Take care to ensure that the path entered is unaltered, even down to subtle changes such as character case, in the example Active Roles Server the path must be ARServerAdmin. |
You can now configure how the application is displayed on the Cloud Access Manager Portal. Enter the Title and Description you want to display on the Cloud Access Manager Portal. Many applications will require you to configure a particular entry point, for example for Active Roles Server you would need to add ARServerAdmin in the URL field of the Application Portal page.
|
NOTE: Take care to ensure that the URL entered is unaltered, even down to subtle changes such as character case, in the example Active Roles Server the URL must be ARServerAdmin. The Add application to application portal home and Allow user to remove application from application portal options allow you to specify whether the application should appear automatically on each user’s portal page, and how the user can manage the application from the application portal. The options are shown in the table below. |
Add application to application portal home | Allow users to remove application from application portal home | Functionality |
---|---|---|
application is added to the portal and it cannot be removed by the user through the application catalog. | ||
application is added to the portal and it can be removed by the user through the application catalog. | ||
application is not automatically added to the portal. The user can add or remove the application to/from the portal through the application catalog. |
To access the application catalog from the application portal, the user simply needs to click their username, then select Application Catalog. Depending on the settings in the Add application to application portal home and Allow user to remove application from application portal home options, the user can add or remove applications to/from the application portal.
© ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center