This example uses Microsoft AD FS v2 to federate users using SAML 2.0. However, it should be possible to use any SAML 2.0 compliant IDP.
To configure SAML federated authentication
Log in to the Administration Console and select Add New from the Front-end Authentication section on the home page.
|
NOTE: If SAML federation is enabled, users primary credentials will not be populated on user login, this is because SAML tokens do not include the password. Users will need to populate their primary credentials manually in a one time task, either in the Cloud Access Manager Password Wallet, or when they first access an application that requires their primary credentials. Please note, this applies to other Front-end Authenticators that do not provide a user password on login, for example Smart card authentication or Kerberos authentication. |
In the Federation Metadata URL field, enter the federation metadata URL provided by your IDP. The example URL shown below can be found in ADFS Management Console | Service | Endpoints | Metadata.
https://<Host FQDN>/FederationMetaData/2007-06/FederationMetaData.xml
Alternatively, click Browse to locate the file containing federation metadata. Refer to your IDP configuration interface for assistance with locating this information.
If you have entered the federation metadata URL as described above, click Next and skip to Step 6.
Click Browse to locate and upload the contents of the IDP's public signing certificate in Base-64 encoded X.509 (.CER) format.
For AD FS v2, this certificate is known as the Token-signing certificate. To obtain the certificate from the AD FS host, open the AD FS 2.0 management console, click Service | Certificates, then double-click the Token-signing certificate. From here, click Copy to file to save the certificate.
In the Authenticator Name field, enter the name that will be used to identify the authenticator within Cloud Access Manager, then click Finish.
The Front-end Authentication Method Created page is now displayed. Leave this page open.
It is recommended that you use the metadata produced by Cloud Access Manager to configure the trust relationship with the STS.
Otherwise, select Enter data about the relying party manually and click Next.
Click Finish.
|
NOTE: By default Cloud Access Manager will perform authorization based on claims of the type Role. If you use a different claim type you will also need to change the claim type within Cloud Access Manager during the Role Mappings configuration. |
To support single sign out, logout requests from Cloud Access Manager need to be signed. If you use metadata to configure AD FS then the certificate will have been loaded already.
If you are configuring manually:
You now need to add the certificate to Trusted Root Certification Authorities so that it is trusted by ADFS. Go to the Signature tab in the ADFS Properties and click View... if the certificate is not trusted you will see a warning similar to the one below.
To allow the certificate to be trusted:
The certificate is now trusted. You can confirm this by closing and re-opening the certificate dialog. The certificate will now appear as below.
Before Cloud Access Manager administrators and users can log in to Cloud Access Manager using their federated identity, you must tell Cloud Access Manager how to identify administrators and users based on their claims. For AD FS v2, the claim could be an AD group name in a role claim. For example, the Domain Admins group for Cloud Access Manager administrators and the Domain Users group for regular Cloud Access Manager users.
|
NOTE: By default Cloud Access Manager will look for claims of the type role. If you configured claims of a different type, update the Allow users with a claim named field with the different type. |
Click Save.
The configuration is now complete. Cloud Access Manager administrators and users can now log in to Cloud Access Manager using their Active Directory federated credentials. For example, users who belong to the AD Domain Admins security group will be able to log in and configure Cloud Access Manager and all domain users will be able to log in to the Cloud Access Manager portal using their federated identity.
|
NOTE: To fully support logout from AD FS, you must configure AD FS to not use integrated authentication. Once an NTLM connection has been established it will be retained in the browser for its lifetime, and will be used for all connections between the browser and AD FS. Logout from AD FS will appear to work, but on the next connection to AD FS the browser will use the cached connection details and you will be logged on without requiring re-authentication. |
This example uses Microsoft AD FS v2 to federate users using WS-Federation.
To configure WS-Federated authentication
https://dc01.qctest.local/FederationMetaData/2007-06/FederationMetaData.xml
Alternatively, click Browse to locate the file containing federation metadata. Refer to your IDP configuration interface for assistance with locating this information.
If you have entered the federation metadata URL as described in this step, skip to Step 6.
Click Browse to locate and upload the contents of the IDP's public signing certificate in Base-64 encoded X.509 (.CER) format.
For AD FS v2 this certificate is known as the Token-signing certificate. To obtain the certificate from the AD FS host, open the AD FS 2.0 management console, click Service Certificates, then double-click the Token-signing certificate. Click Copy to file to save the certificate.
We will now switch to AD FS and configure Cloud Access Manager as a Relying Party.
On the ADFS host, open the AD FS 2.0 management console and click Add Relying Party Trust.
It is recommended that you use the metadata produced by Cloud Access Manager to configure the trust relationship with the STS.
On the second row, select an LDAP Attribute of Token-Groups - Unqualified Names and an Outgoing Claim Type of Role.
|
NOTE: By default Cloud Access Manager will perform authorization based on claims of the type Role. If you use a different claim type, you will also need to change the claim type within Cloud Access Manager during the Role Mappings configuration. |
Before Cloud Access Manager administrators and users can log in to Cloud Access Manager using their federated identity, you must tell Cloud Access Manager how to identify administrators and users based on their claims. For AD FS v2, the claim could be an Active Directory group name in a role claim. For example, the Domain Admins group for Cloud Access Manager administrators and the Domain Users group for regular Cloud Access Manager users.
|
NOTE: By default, Cloud Access Manager will look for claims of the type role. If you configured claims of a different type, update the Allow users with a claim named field with the different type. |
Enter Domain Admins into the Having value field, then click Save.
The configuration is now complete. Cloud Access Manager administrators and users can now log in to Cloud Access Manager using their Active Directory federated credentials. For example, users who belong to the Active Directory Domain Admins security group will be able to log in and configure Cloud Access Manager, and all domain users will be able to log in to the Cloud Access Manager portal using their federated identity.
|
NOTE: To fully support logout from AD FS, you must configure AD FS to not use integrated authentication. Once an NTLM connection has been established it will be retained in the browser for its lifetime, and will be used for all connections between the browser and AD FS. Logout from AD FS will appear to work, but on the next connection to AD FS the browser will use the cached connection details and you will be logged on without requiring re-authentication. |
Social authenticators allow users to link third party authenticators, for example Facebook, Google, Twitter and Microsoft Live ID, with their Cloud Access Manager account.
Social authenticators are presented to users as links on the login page. The first time a user clicks one of these links they will authenticate with the third party web site. On returning to Cloud Access Manager, the user is asked to authenticate using their Cloud Access Manager credentials in order to link the two accounts together.
For future logons, the user will only need to authenticate using either third party credentials or their Cloud Access Manager credentials. The user can unlink the accounts using the Manage Links option on the Navigate Menu on the Cloud Access Manager home page. The following example uses Microsoft Live ID as the third party authenticator.
|
NOTE: In order to use Microsoft Live ID as a third party authenticator, a Microsoft account Developer Center application is required. |
To configure Microsoft Live ID as a social authenticator
In the Authenticator Name field, enter the name that will be used to identify the authenticator within Cloud Access Manager, then click Finish.
|
NOTE: This name will be seen by Cloud Access Manager users during authentication as an alternative authentication option. |
Configuration of Microsoft Live ID as a social authenticator is now complete.
|
NOTE: Use of social authenticators must be enabled per directory authenticator, please refer to Microsoft Active Directory authentication and LDAP authentication for details on enabling social authentication for a directory authenticator. |
When users authenticate using a directory authenticator, for instance Active Directory or Lightweight Directory Access Protocol (LDAP), Cloud Access Manager can link to password management software to allow users to reset their passwords or unlock their accounts.
If the link between Cloud Access Manager and the password management software is configured, users will see a Forgot Password? link either before authentication, or if authentication fails. In either situation, clicking the link will redirect the user to the password management application.
If password expiry reminders are enabled, and a user's password is due to expire soon, the following dialog is displayed:
Click Yes to open a new tab in the browser and load the password management application. If a user specific URL is configured, information about the authenticated user is communicated to the password management application.
To configure a password management application
To configure a user specific URL for when the user's password is about to expire
In the Password Management Options section enter a URL in the URL of password management application with user information field. The following parameters may be inserted into the URL.
Parameter | Functionality |
---|---|
{id} |
The unique identifier for the user |
{username} |
The user part of the user's login name |
{domain} |
The domain part of the user's login name |
{displayName} |
The user's display name |
{emailAddress} |
The user's email address |
The following example shows how to pass the domain and user name to Cloud Access Manager; replace password.host with the Domain Name Service (DNS) name of your Password Manager installation:
https://password.host/QPMUser/EntryPoint/?ActionName=ResetPassword&IdentificationDomain={domain}&IdentificationAccount={username}
To configure the user’s password expiry alert
In the Password Management Options section enter the number of days before the password expiration reminder will be displayed. To prevent users being notified that their password is about to expire, set this value to zero.
|
NOTE: If you do not enter a user specific URL, but password expiry notifications are enabled, Cloud Access Manager will use the standard password management application URL. |
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center