1 DocuSign Single Sign On Implementation Guide Published: March 17, 2016
2 Copyright Copyright DocuSign, Inc. All rights reserved. For information about DocuSign trademarks, copyrights and patents refer to the DocuSign Intellectual Property page (https://www.docusign.com/ip) on the DocuSign website. All other trademarks and registered trademarks are the property of their respective holders. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of DocuSign, Inc. Under the law, reproducing includes translating into another language or format. Every effort has been made to ensure that the information in this manual is accurate. DocuSign, Inc. is not responsible for printing or clerical errors. Information in this document is subject to change without notice.
3 Table of Contents Table of Contents DocuSign Single Sign On Overview 4 Setting Up Single Sign On for Your Organization 4 Supported Protocols 5 DocuSign Single Sign On Permissions 6 DocuSign Access - Which users should have access to DocuSign? 6 Login Policy - How do you want users to log in? 6 Account Membership and Permissions 7 Domains 9 Reserve a Domain 9 Get a Token 11 Withdraw a Domain Claim 12 Change Domain Level Settings 12 Setting User Login Policy 14 Identity Providers 16 Set Up an Identity Provider 16 Edit an Identity Provider 19 Adding and Updating Certificates 19 Testing an Identity Provider Configuration 19 SAML Specifications 20 3
4 4 DocuSign Single Sign On Overview Single Sign On, also known as Federation, provides a secure way to exchange authentication information between two parties, a Service Provider and an organization s Identity Provider, allowing a single set of credentials to be used to access multiple applications. When an organization enables Single Sign On (SSO) for their DocuSign account, it allows members to use their organization s credentials to access DocuSign. DocuSign allows administrators to manage users in a specific domain. Suppose every user at an organization has an address at the By proving ownership of myorganization.com, an administrator can manage the identity for DocuSign users on that domain. For example, an organization can enable a security policy in DocuSign to require all users with their address to authenticate with the corporate Identity Provider. This process is known as federation or SSO. With SSO administrators can manage DocuSign users from their organization s Identity Provider. This streamlines the process of managing users by allowing the use of a central system for administration, provisioning new users, resetting passwords, changing logon policies, and deactivating users. For account users this is beneficial because it allows them to only need one user name and password for everything at work from computer, , to DocuSign. This guide provides information about setting up and managing SSO with your DocuSign account. The information in this guide is also available in the DocuSign Support Center. Note: SSO only controls authentication and user access into DocuSign. It is not a replacement for setting user permissions. Administrators will still need to modify permissions through the DocuSign web application or DocuSign API. Setting Up Single Sign On for Your Organization Important: Single Sign On functionality is only supported in DocuSign Enterprise plans. Your account might not support this option. To access this functionality, contact your Account Manager. This section provides a high-level overview that most organizations will follow to enable Single Sign On (SSO). Before setting up SSO, you should review the DocuSign Single Sign On Permissions for additional aspects that SSO administrators should consider when setting up SSO. Note: These actions can only be taken by users who have been designated as the organization administrators. This is a special configuration that can only be enabled internally by DocuSign. Please contact your account manager to enable these privileges or change organization administrators. The basic steps to setting up SSO for your organization:
5 5 Note: DocuSign recommends doing these steps in your Demo account first. Then, when successful, repeat the same steps in your Production account. 1. An organization must, first, prove ownership of the domain in order to manage it. During this step organization administrators follow the process in DocuSign Admin to create a reserved domain. Refer to Claim a Domain for the procedure and details for doing this. 2. Set up and configure an Identity Provider in DocuSign. In this step the organizational administrator provides SAML configuration to allow DocuSign to establish interoperability with the Identity Provider. Refer to Set up an Identity Provider for the procedure and details for doing this. 3. Test the SSO configuration with a select group of users. Before making SSO mandatory for all users in the organizations, you will test the SSO configuration with a small group of users to ensure SAML has been configured correctly. Refer to Testing an Identity Provider Configuration for the procedure and details on doing this. 4. Make SSO mandatory for all users. The final step is to make SSO mandatory. This requires all users on the domain to authenticate with the Identity Providers. Any pre-existing user names and passwords in DocuSign are no longer valid. Refer to the Change Domain Level Settings procedure to set the security options for your account. Supported Protocols DocuSign SSO currently supports the following SAML protocols: OASIS SAML 2.0 with HTTP POST binding
6 6 DocuSign Single Sign On Permissions With a basic understanding of how Single Sign On (SSO) works, it s now important to reflect on the permissions and authorization rules that an organization may want to enforce. Such policies could change the way you configure DocuSign or the Identity Provider. This section covers several aspects that SSO administrator should consider when setting up SSO. DocuSign Access - Which users should have access to DocuSign? Every DocuSign customer might have different preferences or policies regarding which users are allowed to access DocuSign. Some organizations might allow every user to have the ability to access DocuSign to send and receive documents. However, some customers only want to provision DocuSign for certain groups of users in the organization. When using SSO, the limited access type of policy is configured within the Identity Provider. If a user tries to access DocuSign and they are not permitted to use DocuSign, then the Identity Provider should deny its access by rejecting the SAML authentication request for that user. Checklist Item: Ensure your Identity Provider has been configured correctly. Either it allows access for all users or the Identity Provider is configured to restrict DocuSign access to specific security groups. Login Policy - How do you want users to log in? For SSO, most organizations require users to log on with their Identity Provider via SAML. In almost all cases, once SSO is turned on it replaces username/password as the method for the authentication. This makes any existing username/password combinations in DocuSign unusable. However, there is an exception to this rule. There can be circumstances where certain users still retain a username/password within DocuSign that would be active even when SSO is enabled. Such scenarios could include giving the SSO administrator the ability to log on in the event that there is an SSO configuration problem or there might be a need for certain client integrations to have a username/password so it can work with DocuSign s APIs. In general, there is a way to provide an exception to the SSO policy for certain users. However, it should only be done for highly privileged users since it creates an exception to your SSO policies. Checklist Item: Identify the users and integrations that might need the privilege of retaining a direct username/password log on into DocuSign.
7 7 Account Membership and Permissions When a user logs on for the first time, they may not have an existing identity in DocuSign. For this case DocuSign will create a user in the system on the fly. This feature is called Just-In-Time Provisioning. Part of this process requires DocuSign to make a decision on which account the user should be a member of and the allowed permissions for that user. There are two main patterns that can be implemented: 1. DocuSign internally configures a single default account and permissions set for any user that is created with Just In Time provisioning. After a user is created, they may be manually added to other accounts or given different permissions using DocuSign Admin or the DocuSign API. Pros: Cons: This is the simplest method to configure SSO and requires no additional configuration in the Identity Provider. Great for keeping users in a default account, until they can follow the organization s approval process to be given additional permissions or access to other accounts. This process would happen outside of SSO. This means all users will start with the same account memberships and same set of permissions. 2. The Identity Provider specifies the account and permissions in the in the incoming SAML assertion when the user is created. Pros: Cons: This provides greater flexibility, ensuring each user is specifically created in the appropriate account with appropriate permissions. This can be tied to permission and security policies within your Identity Provider so that rules such as People in HR, get added to the HR account can be followed. This requires custom configuration in your Identity Provider to specify the attributes and rules applied for each new user. This is more complicated and harder to troubleshoot since policies are configured in a system outside of DocuSign s control.
8 8 Checklist Item: Talk with application administrators about what configurations must be enforced to comply with the organization s policies. It is likely that pattern #1 will be sufficient for most customers. As an organization s adoption of DocuSign matures, the more sophisticated measures of pattern #2 can be implemented.
9 9 Domains DocuSign allows organization administrators to reserve domains for use with DocuSign. This allows the system administrators to manage users for specific domains. An organization can reserve multiple domains. DocuSign verifies domain ownership before any organization can manage it. To reserve a domain, the administrator adds the domain to their organization DocuSign Admin. DocuSign then generate a special token that must be added to the DNS record for the domain. Once DocuSign recognizes this token in the DNS entry, this confirms that the organization owns and operates the domain. IMPORTANT: A domain can only be managed by one organization. If one organization has claimed and verified a domain, then another organization cannot claim or manage it. From this page you can do the following: Reserve a domain Get a Token Withdraw a claim Change domain level settings This topic also provides information on Setting User Login Policy. Note: These options can only be modified by users who have been designated as the organization admin. This is a special configuration that can only be enabled internally by DocuSign. Please contact your account manager to acquire these privileges. Reserve a Domain Note: An organization can reserve multiple domains. DocuSign recommends that you repeat steps 2 6 of the following procedure for each domain, so you only need to update your DNS once (step 7) and can validate domains (step 8) at the same time. 1. In the DocuSign Admin application, click Domains. 2. Click CLAIM DOMAIN.
10 10 3. Enter the Domain Name. 4. Click CLAIM. If the domain has already been verified by another organization, you must enter a different name. If you have questions about domain names, contact your account manager. If the domain is available, a TXT token is generated and shown in the dialog box. Continue to step 5.
11 11 5. Copy the generated TXT token so that it can be added to your domain s DNS entry. 6. Click CLOSE. 7. Outside of the DocuSign Admin application, update your domain s DNS entry to include the generated TXT token. The TXT token cannot be removed from the DNS record. DocuSign periodically checks the DNS to ensure claims are valid and removal of the TXT token would prevent your users from accessing DocuSign. Note: The process of updating DNS records varies by vendor. You might need to coordinate with your network administrator in order to make this change. Also, it may take up to 72 hours for DNS changes to propagate over the Internet. Therefore coordinating ahead of time will ensure timely deployment of Single Sign On. As a sanity check, you check if the DNS change is active by opening command prompt in Windows and typing in this command: nslookup q=txt [myorganization.com] Where [myorganization.com] is the domain you are checking. 8. Once the DNS change is active, return to the DocuSIgn Admin application and click DOMAINS. 9. Find the domain in the list, click ACTIONS on the same line as the domain name and select Validate. DocuSign checks to see if the generated token is part of the DNS entry. If successful the domain is marked with an active status. Note: DocuSign periodically validates any pending domain claims. So it is possible that, after updating your DNS, your domain claim can become active in DocuSign even if you haven t clicked validate. Get a Token Use the following steps to. 1. In the DocuSign Admin application, click Domains. 2. In the list of domains, find the domain for which you want to get the token. Click ACTIONS on the same line as the domain name and select Get Token. 3. Copy the generated TXT token as needed. 4. Click CLOSE.
12 12 Withdraw a Domain Claim You can relinquish control of a domain by withdrawing your domain claim. Releasing a domain removes any security policies and may prevent users from logging on to the DocuSign web application. This operation should only be reserved for cases where you are certain there are no active users with this address. IMPORTANT: There is no way to undo this change. Organizational administrators must be cautious about withdrawing any active domain claims. 1. In the DocuSign Admin application, click Domains. 2. In the list of domains, find the domain you want to relinquish. Click ACTIONS on the same line as the domain name and select Withdraw Claim. 3. Click CONFIRM to withdraw your claim. Change Domain Level Settings Once a domain has been successfully validated you can modify the security settings for the domain. 1. In the DocuSign Admin application, click Domains. 2. In the list of domains, find the domain you want to modify. Click the domain name or click ACTIONS on the same line as the domain name and select Edit. 3. Select the security options you d like to enable.
13 13 Select the appropriate options for this domain: Always require login when opening envelopes: When a user with the domain receives a document, they must first log on before they can open the document. Prevent unmanaged signups: This prevents users from using the self-serve sign up to register for a new DocuSign account using your domain. All users must either be created by the administrator or the Identity Provider. Require all users to authenticate with identity provider: All users are required to use the Company Login button to log on to the DocuSign web application with your organization s Identity Provider. Only enable this setting once you have added and tested an Identity Provider configuration, otherwise users may not be able to log on to DocuSign. 4. Click SAVE to save the changes.
14 14 Setting User Login Policy When SSO is enabled for an organization, all account users follow the policy settings specified for the domain. For example, an organization s domain is myorganization.com. If the organization administrator requires all users to authenticate with an Identity Provider, then all users with address are required to authenticate with their corporate credentials. There might be cases where using the default policy might not be appropriate for all users. Some examples of this are: The organization administrator might want to retain the ability to maintain a username and password in DocuSign. This is helpful for cases where the administrator needs to access DocuSign to make updates to the organization s SSO configuration going through the Identity Provider. An application or integration user cannot log in through an Identity Provider because that particular application does not currently support SSO. For these cases, organization administrators have the option of setting login policies on a per user. To change the login policy for users the organization administrator follows these steps: Important: Only organization administrators can change the Login Policy for users. This setting deliberately overrides any policies that are enforced on the domain and administrators should primarily use this as an exception rather than a standard rule for all users. 1. In the DocuSign Admin application, click Users. 2. Find the user that will bypass federation. Click the user name or click ACTIONS adjacent to the name and select Edit. 3. Select the Logon Policy option for the user. The available settings are: Default: This setting uses the policies set for the user s domain. Identity Provider or Username/Password: This setting allows a user to maintain a username and password within DocuSign, even when SSO is required for all users in the domain. Identity Provider only: This setting requires a user to log on with an Identity Provider when SSO is optional for users in the domain. 4. Click SAVE to save the change.
15 15 5. Reset the password for this user or instruct the user to request a password reset by clicking the link in the log in page.
16 16 Identity Providers This page is used to manage Identity Providers for an account. An Identity Provider (IdP) is an enterprise service that manages identity and provides identity information to Service Providers so that users can access applications. IdP's communicate with DocuSign via the SAML protocol and may optionally provide a set of claims which are used to map to various business functions at DocuSign. Note: DocuSign Federation supports SAML 2.0 and all assertions must be sent with HTTP POST. From this page you can do the following: Set up an Identity Provider Edit an Identity Provider Add or Update an Identity Provider Certificate This topic also provides information on testing an Identity Provider configuration and the SAML specifications for Single Sign On. Set Up an Identity Provider Note: An organization must claim ownership of their domain before setting up an Identity Provider. This is to ensure that only domain owners have the ability to change the authentication method for its users. Setting up a SAML configuration without claiming a domain will not result in any changes. See Domains for more information on claiming a domain. 1. In the DocuSign Admin application, click Identity Providers. 2. In the Identity Provider view, click ADD IDENTITY PROVIDER.
17 17 3. Enter a Name. The name must be unique within the DocuSign system. The name is a label for this particular Identity Provider setting and has no impact on the other settings. 4. Enter the Identity Provider Issuer. This must match the issuer field in any SAML assertions.
18 18 5. Enter the Identity Provider Login URL. This is the endpoint that handles the SAML Authentication Request. 6. Optionally, enter the Identity Provider Logout URL. 7. Optionally, enter the Identity Provider Metadata URL. 8. Optionally, enable or disable the following settings as needed: AuthN request: Select this option to require that DocuSign sign the AuthN request in SAML. Sign logout request: Select this option to require that DocuSign send a logout request. 9. Select how the AuthN request and logout request are sent. They can be sent via a redirect (GET) or with HTTP POST. 10. Optionally, add any Custom Attribute Mapping. DocuSign requires an assertion to contain the NameID, , first name, and last name of a user and can accept other optional fields (for more details, see the SAML Specifications). You can configure your Identity Provider to match the standard configuration in DocuSign or you can use the Custom Attribute Mapping to configure DocuSign to map those fields to other assertion attributes in your SAML response. Click ADD NEW MAPPING to add a field. Select the appropriate DocuSign Field and then type the Attribute Name that should be mapped to the field. Click ADD NEW MAPPING to add another field, and then select the appropriate DocuSign Field and then type the Attribute Name that should be mapped to the field. 11. Upload at least one valid certificate used by the Identity Provider to sign SAML assertions. 12. Click SAVE to save the Identity Provider information. 13. Add the certificate for the Identity Provider. 14. Test the Identity Provider configuration. 15. Update your Domain level settings as needed. Once you have successfully configured your Identity Provider to work with your organization s DocuSign account, there are additional security options you can set for your account. One security option is to enforce federated log on by requiring any user on your domain to authenticate with Identity Provider. If a user tries to log on with a DocuSign
19 19 password, an error indicates that the domain is federated and the user is required to use the Company Login button. Refer to the Change Domain Level Settings procedure to set the security options for your account. Edit an Identity Provider 1. In the DocuSign Admin application, click Identity Providers. 2. In the Identity Provider view, find the Identity Provider you want to modify. Click the Identity Provider name or click ACTIONS adjacent to the name and select EDIT. 3. Make the needed changes to the Identity Provider. 4. Click SAVE to save the changes. Adding and Updating Certificates 1. In the DocuSign Admin application, click Identity Providers. 2. In the Identity Provider view, find the Identity Provider you want to modify. Click the Identity Provider name or click ACTIONS adjacent to the name you want to modify and select Edit. 3. In the Identity Provider Certificates section, click Add Certificate. 4. A dialog box opens, select the new certificate and click Open. 5. The certificate is added to the list of certificates. 6. Click SAVE to save the changes. Testing an Identity Provider Configuration Once you have successfully claimed a domain and configured an Identity Provider, you can test Single Sign On with your users. DocuSign recommends having a group of users test the configuration in demo and, after that is successful, switch to Production. Instruct your users to do the following: 1. Go to the DocuSign log on page. The log on page used depends on the environment being tested. DocuSign Demo Environment: https://account-d.docusign.com DocuSign Production Environment: https://account.docusign.com 2. Click Company Login. 3. The user enters their and clicks Continue.
20 20 DocuSign checks the to determine the appropriate domain. The user is then redirected to the Identity Provider, via SAML, to complete the logon process. After successfully authenticating, the user is taken to the appropriate account in the DocuSign web application. For new users (users that have not been added to you r DocuSign account), DocuSign will provision them as a new user under your organization s default account; all of this happens automatically without any need for administrator action. Note: DocuSign s just in time provisioning can be configured to create new users in a specific DocuSign account with a specific permission profile. Please consult with DocuSign Support to configure the provisioning settings correctly for your organization. If the tests were successful for all claimed domains, then you can be sure that all users on your domains will be able to successfully log in with your Identity Provider configurations. SAML Specifications DocuSign requires the following SAML configuration in order for federation to work. The list below shows the attributes that are required in your SAML assertions. If the attribute names are different than what has been specified, you can configure DocuSign to capture this data from other attributes in the assertion by mapping the attribute name. See To Set up an Identity Provider for more information on Custom Attribute Mapping. NameId (Required): DocuSign requires a unique identifier for a user. This unique identifier must be immutable and cannot change for a user. In addition to that, this unique identifier cannot be recycled. An address is not a recommended for use as an identifier, since a user can change s or the may be reissued. Instead, DocuSign recommends that customers either use the employee ID or some other unique identifier. A SAML example is provided below: <saml:subject> <saml:nameid> </saml:nameid> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdatarecipient="https://account.dsw docusignh q.com/saml2/login"/> </saml:subjectconfirmation> </saml:subject> Address (Required): The user s address. <saml:attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ address" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> </saml:attribute> First Name (Required): The user s first name.
21 21 <saml:attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>john</saml:attributevalue> </saml:attribute> Last Name (Required): The user s last name. <saml:attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>jones</saml:attributevalue> </saml:attribute> AccountId (Optional): The DocuSign ID for the account associated with the user. If specified, this accountid will be used during just-in-time provisioning. This is the account that the user will be provisioned into when the user is created on first login. The accountid must be the account GUID format. This must be specified in conjunction with the PermissionProfileId below, otherwise login will fail. <saml:attribute Name="http://schemas.account.docusign.com/ws/2015/09/identity/claims/accounti d" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>bb151f08-c631-46c7-b2c2-44a5dca243dd</saml:attributevalue> </saml:attribute> PermissionProfileId (Optional): The DocuSign ID of the Permission Set associated with the user. Permission Sets are sets of account permission settings that can be applied to individual users. Using this option allows new users to be assigned to a permission set when they are added to the account. If specified, this is the permission profile that will be assigned to the user in the above account when the user is created on first login. This must be specified in conjunction with the AccountId above, otherwise login will fail. <saml:attribute Name="http://schemas.account.docusign.com/ws/2015/09/identity/claims/permissi onprofileid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>1</saml:attributevalue> </saml:attribute>
DocuSign Administrator Guide Published: December 20, 2016 Copyright Copyright 2003-2016 DocuSign, Inc. All rights reserved. For information about DocuSign trademarks, copyrights and patents refer to the
Information Guide 1 DocuSign Connect for Salesforce Guide 1 Copyright 2003-2013 DocuSign, Inc. All rights reserved. For information about DocuSign trademarks, copyrights and patents refer to the DocuSign
INTEGRATION GUIDE DIGIPASS Authentication for Salesforce using IDENTIKEY Federation Server Disclaimer Disclaimer of Warranties and Limitation of Liabilities All information contained in this document is
DocuSign Quick Start Guide Using the Payment Processing Feature Overview There might be times when you want to send an envelope where you can send an offer, close the deal and collect the cash all in one
Egnyte Single Sign-On (SSO) Installation for OneLogin To set up Egnyte so employees can log in using SSO, follow the steps below to configure OneLogin and Egnyte to work with each other. 1. Set up OneLogin
DocuSign Quick Start Guide Using Check Boxes and Radio Buttons Overview When adding fields to a document, there might be times when you want to let your recipient select options on the document and you
This chapter provides information about the Security Assertion Markup Language (SAML) Single Sign-On feature, which allows administrative users to access certain Cisco Unified Communications Manager and
SAML SSO Configuration Overview of Single Sign-, page 1 Benefits of Single Sign-, page 2 Overview of Setting Up SAML 2.0 Single Sign-, page 3 SAML 2.0 Single Sign- Differences Between Cloud-Based Meeting
Enabling SAML Single Sign-On with OneLogin Reference Guide 2016 Adobe Systems Incorporated. All Rights Reserved. Products mentioned in this document, such as the services of identity provider Onelogin,
CENTRIFY DEPLOYMENT GUIDE Google Apps Deployment Guide Abstract Centrify provides mobile device management and single sign-on services that you can trust and count on as a critical component of your corporate
Table of Contents Table of Contents Getting Started with Pivotal Single Sign-On Adding Users to a Single Sign-On Service Plan Administering Pivotal Single Sign-On Choosing an Application Type 1 2 5 7 10
SAML Authentication Quick Start Guide Powerful Authentication Management for Service Providers and Enterprises Authentication Service Delivery Made EASY Copyright 2013 SafeNet, Inc. All rights reserved.
Configuring Single Sign-on from the VMware Identity Manager Service to WebEx VMware Identity Manager SEPTEMBER 2015 V 2 Configuring Single Sign-On from VMware Identity Manager to WebEx Table of Contents
DocuSign Quick Start Guide Adding Signer Authentication to an Envelope Overview An important DocuSign feature is the ability to verify the identity of a recipient before they can access documents in an
Security Assertion Markup Language (SAML) Site Manager Setup Trademark Notice Blackboard, the Blackboard logos, and the unique trade dress of Blackboard are the trademarks, service marks, trade dress and
Configuring Single Sign-on from the VMware Identity Manager Service to ServiceNow VMware Identity Manager AUGUST 2015 V1 Configuring Single Sign-On from VMware Identity Manager to ServiceNow Table of Contents
Chapter 83 WebEx This chapter includes the following sections: An overview of configuring WebEx for single sign-on Configuring WebEx for SSO Configuring WebEx in Cloud Manager For more information about
QualysGuard SAML 2.0 Single Sign-On Technical Brief Introduction Qualys provides its customer the option to use SAML 2.0 Single Sign On (SSO) authentication with their QualysGuard subscription. When implemented,
Add Microsoft Azure as the Federated Authenticator in WSO2 Identity Server This blog will explain how to use Microsoft Azure as a Federated Authenticator for WSO2 Identity Server 5.0.0. In this example
Building Secure Applications James Tedrick What We re Covering Today: Accessing ArcGIS Resources ArcGIS Web App Topics covered: Using Token endpoints Using OAuth/SAML User login App login Portal ArcGIS
Introduction to Directory Services Overview This document explains how AirWatch integrates with your organization's existing directory service such as Active Directory, Lotus Domino and Novell e-directory
Tenrox Single Sign-On (SSO) Setup Guide January, 2012 2012 Tenrox. All rights reserved. About this Guide This guide provides a high-level technical overview of the Tenrox Single Sign-On (SSO) architecture,
Getting Started with AD/LDAP SSO Active Directory and LDAP single sign- on (SSO) with Syncplicity Business Edition accounts allows companies of any size to leverage their existing corporate directories
1 HOTPin Integration Guide: Salesforce SSO with Active Directory Federated Services Disclaimer Disclaimer of Warranties and Limitation of Liabilities All information contained in this document is provided
Using SAML for Single Sign-On in the SOA Software Platform SOA Software Community Manager: Using SAML on the Platform 1 Policy Manager / Community Manager Using SAML for Single Sign-On in the SOA Software
Agent for Remote Web Workplace 2010 CRYPTOCard Corp. All rights reserved. http:// www.cryptocard.com Copyright Copyright 2010, CRYPTOCard All Rights Reserved. No part of this publication may be reproduced,
SalesForce SSO with Active Directory Federated Services (ADFS) v2.0 Authenticating Users Using SecurAccess Server by SecurEnvoy Contact information SecurEnvoy www.securenvoy.com 0845 2600010 Merlin House
w w w. e g n y t e. c o m Egnyte Single Sign-On (SSO) Configuration for Active Directory Federation Services (ADFS) To set up ADFS so that your employees can access Egnyte using their ADFS credentials,
Chapter 190 WebEx This chapter includes the following sections: "An overview of configuring WebEx for single sign-on" on page 190-1600 "Configuring WebEx for SSO" on page 190-1601 "Configuring WebEx in
CA Performance Center Single Sign-On User Guide 2.4 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is
SyAM Management Utilities and Non-Admin Domain Users Some features of SyAM Management Utilities, including Client Deployment and Third Party Software Deployment, require authentication credentials with
w w w. e g n y t e. c o m Egnyte Single Sign-On (SSO) Installation for VMware Horizon To set up Egnyte so employees can log in using SSO, follow the steps below to configure VMware Horizon and Egnyte to
Authentication Methods Overview In addition to the OU Campus-managed authentication system, OU Campus supports LDAP, CAS, and Shibboleth authentication methods. LDAP users can be configured through the
Guideline Configuring IBM Cognos Controller 8 to use Single Sign- On Product(s): IBM Cognos Controller 8.2 Area of Interest: Security Configuring IBM Cognos Controller 8 to use Single Sign-On 2 Copyright
Chapter 94 Configuring Salesforce The following is an overview of how to configure the Salesforce.com application for singlesign on: 1 Prepare Salesforce for single sign-on: This involves the following:
Configuration Guide - OneDesk to SalesForce Connector Introduction The OneDesk to SalesForce Connector allows users to capture customer feedback and issues in OneDesk without leaving their familiar SalesForce
HP Software as a Service Federated SSO Guide Document Release Date: July 2014 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty statements accompanying
Cloud Single Sign-On and On-Premise Identity Federation with SAP NetWeaver Cloud White Paper TABLE OF CONTENTS INTRODUCTION... 3 Where we came from... 3 The User s Dilemma with the Cloud... 4 The Administrator
Salesforce.com: Salesforce Winter '09 Single Sign-On Implementation Guide Copyright 2000-2008 salesforce.com, inc. All rights reserved. Salesforce.com and the no software logo are registered trademarks,
Agent for Terminal Services Web and Remote Desktop Web 2010 CRYPTOCard Corp. All rights reserved. http:// www.cryptocard.com Copyright Copyright 2010, CRYPTOCard All Rights Reserved. No part of this publication
Microsoft Office 365 Using SAML Integration Guide Revision A Copyright 2013 SafeNet, Inc. All rights reserved. All attempts have been made to make the information in this document complete and accurate.
DocuSign Quick Start Guide In Person Signing Overview The In Person Signing feature lets you use the DocuSign Service for electronic signatures even if the signer does not have access to email or a computer.
Chapter 82 Configuring Moodle The following is an overview of the steps required to configure the Moodle Web application for single sign-on (SSO) via SAML. Moodle offers SP-initiated SAML SSO only. 1 Prepare
SAML Authentication with BlackShield Cloud Powerful Authentication Management for Service Providers and Enterprises Version 3.1 Authentication Service Delivery Made EASY Copyright Copyright 2011. CRYPTOCARD
DocuSign Quick Start Guide Using the Sign a Document Now Feature Overview You can already send documents out for electronic signature using DocuSign, but what about documents sent to you to sign from outside
Chapter 117 Configuring SuccessFactors The following is an overview of the steps required to configure the SuccessFactors Enterprise Edition Web application for single sign-on (SSO) via SAML. SuccessFactors
Intel Entry Storage System SS4200-E Active Directory Implementation and Troubleshooting 1 Active Directory Overview SS4200-E Active Directory is based on the Samba 3 implementation The SS4200-E will function
CA Nimsoft Service Desk Single Sign-On Configuration Guide 6.2.6 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation
Enabling SAML 2.0 web browser Single Sign-On with Typing Quest The guide applies to the web-based typing tutor sold under the brand name Typing Quest, TypingMaster or NäppisTaituri, depending on program
SafeNet Authentication Service Integration Guide Using SAS SAML-based Authentication with Citrix NetScaler Gateway 10.1 Technical Manual Template Release 1.0, PN: 000-000000-000, Rev. A, March 2013, Copyright
C O L A B O R A T I V E I N N O V A T I O N M A N A G E M E N T Complete Feature Guide SAML Single-Sign-On (SSO) 1. Features This feature allows administrators to setup Single Sign-on (SSO) integration
ADFS for LogMeIn and join.me authentication ADFS for join.me authentication This step-by-step guide walks you through the process of configuring ADFS for join.me authentication. Set-up Overview 1) Prerequisite:
Chapter 40 Configuring Connected Data The following is an overview of the steps required to configure the Connected Data Web application for single sign-on (SSO) via SAML. Connected Data offers both IdP-initiated
Adding Single Sign-On to CloudPassage Halo For Halo Site Administrators Contents: About SAML-Based Single Sign-On Integrating Halo With a Single Sign-On Provider 1. Enable and Configure SSO 2. Configure
Chapter 41 Configuring Salesforce The following is an overview of how to configure the Salesforce.com application for singlesign on: 1 Prepare Salesforce for single sign-on: This involves the following:
HP Software as a Service Software Version: 6.1 Federated SSO Document Release Date: August 2013 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty
Version 27.0: Spring 13 Single Sign-On Implementation Guide Last updated: February 1, 2013 Copyright 2000 2013 salesforce.com, inc. All rights reserved. Salesforce.com is a registered trademark of salesforce.com,
OpenLogin: PTA, SAML, and OAuth/OpenID Ernie Turner Chris Fellows RightNow Technologies, Inc. Why should you care about these features? Why should you care about these features? Because users hate creating
Enabling Integrated Windows Authentication For CitectSCADA Web Client Applies To: CitectSCADA 6.xx and 7.xx VijeoCitect 6.xx and 7.xx Summary: What is the difference between Basic Authentication and Windows
Configuring Single Sign-on from the VMware Identity Manager Service to AirWatch Applications VMware Identity Manager AUGUST 2015 V1 Configuring Single Sign-On from VMware Identity Manager to AirWatch Applications
Using Microsoft Windows Authentication for Microsoft SQL Server Connections in Data Archive 2014 Informatica Corporation. No part of this document may be reproduced or transmitted in any form, by any means
SAM Context-Based Authentication Using Juniper SA Integration Guide Revision A Copyright 2012 SafeNet, Inc. All rights reserved. All attempts have been made to make the information in this document complete
Horizon Workspace Administrator's Guide Horizon Workspace 1.0 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition.
SOA Software API Gateway Appliance 7.1.x Administration Guide Trademarks SOA Software and the SOA Software logo are either trademarks or registered trademarks of SOA Software, Inc. Other product names,
Configuring Single Sign-on from the VMware Identity Manager Service to Dropbox VMware Identity Manager SEPTEMBER 2015 V1 Configuring Single Sign-On from VMware Identity Manager to Dropbox Table of Contents
C E N T R I F Y G U I D E SAP NetWeaver Java SAML configuration guide Abstract Centrify provides mobile device management and single sign-on services that you can trust and count on as a critical component
Authentication Integration VoiceThread provides multiple authentication frameworks allowing your organization to choose the optimal method to implement. This document details the various available authentication
SAML 2.0 SSO Deployment with Okta Simplify Network Authentication by Using Thunder ADC as an Authentication Proxy DEPLOYMENT GUIDE Table of Contents Overview...3 The A10 Networks SAML 2.0 SSO Deployment
PROPALMS VDI Version 2.1 Quick Start Guide for Parallels Virtuozzo Rev. 1.1 Published: JULY-2011 1999-2011 Propalms Ltd. All rights reserved. The information contained in this document represents the current
Alfresco Share SAML Version 1.1 Revisions 1.1 1.1.1 IDP & Alfresco user logs in using saml login page (Added info about saving the username and IDP login date as a solution for the Security concern mentioned
Chapter 67 Configuring SuccessFactors The following is an overview of the steps required to configure the SuccessFactors Enterprise Edition Web application for single sign-on (SSO) via SAML. SuccessFactors
How to create a SP and a IDP which are visible across tenant space via Config files in IS This Documentation is explaining the way to create a SP and IDP which works are visible to all the tenant domains.
DocuSign Quick Start Guide Using Templates Overview This guide provides an overview of how to use a template when creating and sending an envelope. Templates help streamline the sending process when you
Flexible Identity Federation Administration guide version 1.0.1 Publication history Date Description Revision 2015.09.24 initial release 1.0.0 2015.12.11 minor updates 1.0.1 Copyright Orange Business Services
w w w. e g n y t e. c o m Egnyte Single Sign-On (SSO) Installation for Okta To set up Egnyte so employees can log in using SSO, follow the steps below to configure Okta and Egnyte to work with each other.
èè WHMCS LUXCLOUD MODULE Update: 02.02.2015 Version 2.0 This information is only valid for partners who use the WHMCS module (v2.0 and higher). 1.1 General overview 1.2 Installing the plugin Go to your
Step-by-Step guide for SSO from MS Sharepoint 2010 to SAP EP 7.0x Sverview Trust between SharePoint 2010 and ADFS 2.0 Use article Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 Technologies
Deploying CTERA Agent via Microsoft Active Directory and Single Sign On Cloud Attached Storage September 2015 Version 5.0 Copyright 2009-2015 CTERA Networks Ltd. All rights reserved. No part of this document