Single Sign-On User Guide. Cvent, Inc 1765 Greensboro Station Place McLean, VA

Transcription

1 Single Sign-On User Guide 2018 Cvent, Inc 1765 Greensboro Station Place McLean, VA

2 Contents Single Sign-On User Guide... 3 Key Terms... 3 Features Using SSO to Login... 4 Meeting Planners and Survey Authors... 4 OnArrival... 5 Event Websites... 6 Meeting Request Forms...10 Portals...11 Contact Websites...13 Parked Reports...14 Working with SSO...15 Identity Provider Initiated Model...15 Configuration Requirements...16 Implementation Options User Interface (UI) Changes...18 Authentication Procedure

3 Single Sign-On User Guide Welcome to the Single Sign-On User Guide! Single sign-on (SSO) is Cvent s latest method for securing efficient access control. The purpose of SSO is to help you centralize and simplify your user experience. By acting as a central identity authenticator, SSO enables you to send your users directly to Cvent without forcing them to visit Cvent s login page. In this guide, you will learn the basic steps to setting up SSO within your account. In addition, the guide outlines the SSO standards Cvent supports, the configurations needed to add your SSO login details to an account, and the process of implementing SSO. For more information, please submit a case through the Cvent Community. This process relies on client systems to authenticate the user s credentials within their own system before the user is directed to Cvent s application. NOTE Key Terms Security Assertion Markup Language (SAML): An XML-based standard for exchanging authentication and authorization data between security domains. Identity Provider (IdP): The producer of assertions. Service Provider (SP): The consumer of assertions. Federated ID: An identifier that the client provides for the purpose of ensuring that IDs are consistent. 3

4 Features Using SSO to Login Hotels, Meeting Planners, and Survey Authors Endpoint In a Cvent production account, the endpoint of a meeting planner login should be: If you are setting up SSO in a sandbox environment, the endpoint should be: Note: Cvent will provide you with your account stub or a sandbox account upon request. RelayState An optional RelayState parameter can be included in the assertion. This determines the page on which the user will land after successfully logging into Cvent through SSO. For example, a user can be taken directly to an RFP that they received immediately after authenticating, rather than landing on their default homepage and manually navigating to that RFP. Provisioning SSO cannot be the mechanism for provisioning meeting planner users. This is a licensing restriction. You must manually provision these users. Assertion Attributes You can include the following attributes in your assertion payloads. The fields with an asterisk (*) are required: Note: The NameID of the assertion must match the Federated ID attribute when Federated SSO is being used or the Username attribute when Direct SSO is being used. User Field Federated ID Username* First Name* Last Name* Prefix Title Company Address* Address 1 Address 2 Address 3 City State Code Zip/Postal Code Country Code Attribute federated_id username first_name last_name prefix title company _address address1 address2 address3 city state_code postal_code country_code 4

5 Home Phone Work Phone Home Fax Work Fax Mobile Phone Pager Number User Custom Fields home_phone work_phone home_fax work_fax mobile_phone pager_number field_stub1 field1 Only required when configuring Federated SSO 5

6 OnArrival To enable SSO for OnArrival, you must have SSO for Meeting Planners already set up. If you already have it, contact your customer success consultant to setup SSO for OnArrival. If you do not have it, contact your customer success consultant to turn on SSO for your account. For more information on SSO for meeting planners, refer to page 4. To setup SSO for OnArrival, complete the following steps: 1. Create your unique subdomain. Only one subdomain per configuration is available. 2. Input the unique subdomain value into OnArrival to trigger the SSO request. 3. Notify your customer success consultant of the login interface URL. After you have notified your customer success consultant, you will be redirected back to OnArrival, and will be able to login. If your login credentials have been input incorrectly, you will receive an error message. If this occurs, retry your credentials and make sure they are typed in correctly. If they are correct and you are still receiving an error, contact your customer success consultant for assistance. 6

7 Event Websites With SSO, you can validate invitees prior to their registration for an event. You can also use SSO to send a full contact profile to Cvent. Note: This is only appropriate if your invitees are able to interact with your identity store. Endpoint The endpoint is consistent. This is where you submit your SAML assertion to have the user sign on: Note: Cvent will provide you with your account stub upon request. If you have been provisioned with a sandbox account for SSO testing, then the SAML consumption endpoint should be: Relaystate You need to define the RelayState in the assertion. This determines whether the invitee will be sent to the Registration page or the Summary page once the SSO is validated. The RelayState component can be dynamically generated by Cvent by enabling an external authentication process for the event using the URL that is generated by your Identity Provider system. To do this, open the event in Cvent and go to Events > Website & Registration > Website > Security. Then, under the Website Authentication section, select Use an external authentication process and enter the authentication URL. When someone arrives at the event website or attempts to register for the event (depending on which option is selected), Cvent will redirect that user to the login page and dynamically append the RelayState parameter to the URL. This will allow the same authentication URL to be utilized across all events. Note: If your invitees will determine their registration type by going through a custom process, make sure the Display personal information for invitees who arrive from a Cvent option is set to Yes. Assertion Attributes The SSO process for invitees varies from the process for meeting planners on page 4. For the invitee process, there is no Username, Federated ID, or Password attribute. The required fields are First Name, Last Name, Address, and Source ID. You can see the names of the contact profile attributes on page 7. Note: The NameID of the assertion must match the Address attribute. Required Fields first_name last_name _address source_id 7

8 Optional Fields Field Name Passing Parameter Max Length Contact Type Code reg_code 30 Prefix prefix 30 Designation designation 30 Middle Name middle_name 30 Nickname nickname 30 Company company 100 Title title 50 Home Address 1 home_address1 40 Home Address 2 home_address2 40 Home Address 3 home_address3 40 Home City home_city 40 Home State Code home_state_code unlimited Home Postal Code home_postal_code 25 Home Country Code home_country 3 Home Phone home_phone 30 Home Fax home_fax 30 Work Address 1 work_address1 40 Work Address 2 work_address2 40 Work Address 3 work_address3 40 Work City work_city 40 Work State Code work_state_code unlimited Work Postal Code work_postal_code 25 Work Country Code work_country 3 Work Phone work_phone 30 Work Fax work_fax 30 Mobile Phone mobile 30 Pager pager 30 Reference ID ref_id 100 Target Landing Page target ~ Internal Survey Question Fields question_code1 30 question_answer1 Custom Contact Fields* field_stub1 36 field1 300 Timestamp timestamp 10 Signature reg_signature unlimited 8

9 How do you assign names to contact custom fields? Here is an example of field_stub1 and field1, you can find the field stub in Admin > Account > Account and select Custom Contact Fields from the View dropdown. </Attribute> <Attribute Name= field_stub1 NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:basic > <AttributeValue xmlns:q5= p6:type= q5:string xmlns:p6= >ba2e1901-6efc-4b5c f0a5d</attributevalue> </Attribute> </Attribute> <Attribute Name= field1 NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:basic > <AttributeValue xmlns:q5= p6:type= q5:string xmlns:p6= >ClientValueHere</AttributeValue> </Attribute> 9

10 To add multiple user custom fields, you must specify each custom field counting up from field_stub1 with a corresponding field1 value. field_stub1 field_stub2 field_stub3 field1 field2 field3 What would one of these fields look like in an XML node? Here is an example of RegCode, which is used to determine which registration path an invitee is sent to: </Attribute> <Attribute Name= Reg_Code NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:basic > <AttributeValue xmlns:q5= p6:type= q5:string xmlns:p6= >GoldMember</AttributeValue> </Attribute> 10

11 Meeting Request Forms Cvent supports SSO for individual meeting request forms. Endpoint In a Cvent production account, the endpoint of a meeting request form should be: Note: Cvent will provide you with your account stub upon request. [Guest_Side_URL] is the link to the form. If you have been provisioned with a sandbox account for SSO testing, then the endpoint for the request form is: Relaystate Notice that the relaystate is referenced in the endpoint. For 80% of clients, this is not an issue. But 20% use SSO tools that need consistent endpoints. For these clients, the RelayState= portion can be dropped from the endpoint URL. However, it must be referenced in the SAM response. Provisioning Users of a request form can be provisioned via the SSO process. This alleviates the need to manually add or rely on API to add the users. Note: There is a flag that Cvent needs to activate for this to work. Profile Updating The user profile can be updated via the assertion except for the Federated ID, which is used to match. Administrators can also have their profiles updated via the assertion. Assertion Attributes This is identical to the list on page 4 for meeting planners. 11

12 Portals Cvent supports SSO for portals. Endpoint In a Cvent production account, the endpoint of a portal should be: id]?relaystate=[portal_url] Note: Cvent will provide you with your customer ID and Portal_URL upon request. Relaystate Notice that the relaystate is referenced in the endpoint. For 80% of clients, this is not an issue. But 20% use SSO tools that need consistent endpoints. For these clients, the RelayState= portion can be dropped from the endpoint URL. However, it must be referenced in the Relaystate Node of the assertion payload. Provisioning SSO cannot be the mechanism for provisioning portal users. This is a licensing restriction. You must manually provision these users. Profile Updating Portal users can have their profiles updated via the assertion. Assertion Attributes You can include the following attributes in your assertion payloads. The fields with an asterisk (*) are required: User Field Federated ID* Username* First Name* Last Name* Prefix Title Company Address* Address 1 Address 2 Address 3 City State Code Zip/Postal Code Country Code Home Phone Work Phone Home Fax Work Fax Mobile Phone Attribute federated_id login firstname lastname honorificprefix title company streetaddress streetaddress2 streetaddress3 city state zipcode countrycode homephone workphone homefax workfax mobilephone 12

13 Pager Number User Custom Fields* pager field_stub1 field1 13

14 Contact Websites Endpoint In a Cvent production account, the endpoint of a contact website should be: Note: Cvent will provide you with your account stub upon request. [Guest_Side_URL] is the link to the website. If you have been provisioned with a sandbox account for SSO testing, then the endpoint for the contact website is: Relaystate Notice that the relaystate is referenced in the endpoint. For 80% of clients, this is not an issue. But 20% use SSO tools that need consistent endpoints. For these clients, the RelayState= portion can be dropped from the endpoint URL. However, it must be referenced in the Relaystate Node of the assertion payload. Profile Updating Contacts can have their profiles updated through the assertion. Assertion Attributes Attributes are identical to those for event websites on page 7. The First Name, Last Name, and Address fields are required. If any of these fields are missing, the user will be redirected to the contact website s login page. Additional Info If someone s contact type has visibility rights to the website, you should direct them to the configured landing page. If someone s contact type does not have visibility rights to the website, you should direct them to the login page and display the existing No Access error message. 14

15 Parked Reports Note: You cannot use this feature to create users as you go. Endpoint In a Cvent production account, the endpoint of a parked report should be: The relaystate s URL (RelayState=[Guest_Side_URL]) will be the parked report s URL. Note: Cvent will provide you with your account stub upon request. [Guest_Side_URL] is the link to the parked report. If you have been provisioned with a sandbox account for SSO testing, then the endpoint for the parked report is: The parked report s URL will be RelayState=[Guest_Side_URL]. Relaystate Notice that the relaystate is referenced in the endpoint. For 80% of clients, this is not an issue. But 20% use SSO tools that need consistent endpoints. For these clients, the RelayState= portion can be dropped from the endpoint URL. However, it must be referenced in the Relaystate Node of the assertion payload. Profile Updating The Administrator profile can be updated via the assertion except for the Federated ID, which is used to match. Assertion Attributes This is identical to the list on page 4 for meeting planners. 15

16 Working with SSO Identity Provider Initiated Model Cvent s SSO method follows the identity provider (client) initiated model. Cvent acts as the SP, hosting the Cvent resource for which the user requests access. Using an HTTP POST binding technique, Cvent passes an SAML assertion through the user s web browser to a designated location in the Cvent application. The origin of the assertion is then verified via public/private key cryptography and used to determine the user s identity. If the process is successful, the user will be given access to the Cvent resource. The process: 1. The IdP requests credentials from the user. 2. The user provides valid credentials and is provided a local security context. 3. The user chooses to navigate to the remote resource (via a menu option or link to Cvent). 4. The IdP s SSO service builds a SAML assertion, signs it with an XML signature, and places it within a <Response> message. This message is placed in a HTML form as a hidden form control called SAMLResponse, and sent back to the user s browser. 5. The <Response> message is posted to a designated location on the SP (Cvent s) site. This either happens automatically through an auto-submit script, or manually through the action of the user. 6. The SP parses the <Response> message, validates the XML signature to verify the message origin, and captures the identity information from the assertion. The SP compares the identity information with its internal user records. If there is a match, a new local security context is created for the user within the SP site. 7. If the user has the proper authorization, then the user s browser is redirected to the Cvent resource. 16

17 Configuration Requirements To begin setting up SSO, you will need to provide Cvent with the following: Client Public Encryption Key Static HTML Custom Header Image Client Public Encryption Key This solution uses public/private key cryptography to authenticate the origin of the SAML assertion. To verify a message s signature value, the client must provide Cvent with the public key of their public/private key pair. The public key will be used to sign the assertion message. It should be delivered as a certificate represented in Base64. Provide your assigned Cvent Client Services personnel with a text version of the X509 node from your certificate. Example: <X509Certificate>JI2C/jCCAeagAwIBAgIQYOXU5SeLuK5HTzuRHv7lWTANBgkqhkiG9w0BAQsFADA7MTkwNwY- DVQQDEzBBREZTIFNpZ25pbmcgLSBkZWhlci5mZWRlcmF0aW9uLmFkaWRhcy1ncm91cC5jb20wHhcNMTEw- NDE4MjAwMzIwWhcNMTIwNDE3MjAwMzIwWjA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBkZWhlci5m- ZWRlcmF0aW9uLmFkaWRhcy1ncm91cC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDlABIySzAkx+uDvHnw1Lv8lqdvUq5sMbwUHIBTynEtW82Bpsz6H+Ta0ACTKAr6QFzoviLKtiMY6n/4o4wT16eC1We7VowrcFTlhhjCDNrmO4E1SROT6C70lHg8GCvagy6rkcni/2vmX3dMgsmjbjcLsW2H80aQp2x2XufsuKeSBKweuqd- COTLgfpR+Ka94bH4C+0NxDbRhJkJREJuu3Y5hDJ/B0jw1MNgJBeFbfDWQkW94GccxadI8j8rCr8XmV5yP7YTiqjD/ BDu5X6TqPaBQa+6NDYmjRaTngZ3CzbR1GRbG3MZ2Cz+9kKvU87F/oFMpEx+mp9I2Pe5FDUpP4AbfAgMBAAEwD- QYJKoZIhvcNAQELBQADggEBAH5udTVcGT6eJmzqz3kqAn/XR8LyTsxceIU0EdROy8HRrU8rryKBawtk+vKM8/JLC7X- N4oFJ6B4c0RrEC0GLDs/aldN2zGaMJl+M5pCjhUU1kQS+sW6TXypZ5zaPE1Lqac2NdA2JuQUUjGNd82zTmtIOM/jwEKLSO/ mwe1lm24cbswzy0+c92v1qvrea7yebi0bs9ojkbv7x1pou9+hdvhxcgrkyoi6oc6cl2rhlu4dgplz+a08v/yy0agh97/4bxnoffrhikudtg47wcsxhjy9kb6ad4cm3mwq+mthg3vsdhyfluzsdz2/bktbgumdsuwuw4xzyecqjjftkekoohl=</x509certificate> Static HTML At the time of configuration, the client will provide static HTML blocks that will be displayed in Cvent for the following scenarios: Login Page: If users attempt to access the application from the Cvent login page, they will see a static page with a link redirecting them to an internal page. This page should explain why they cannot access the application, tell them what to do next, and provide a link to an internal site. Logout Page: When users click Logout, they will no longer be directed to the Cvent login page. Instead, they will be directed to an internal SSO login page when attempting to log back in. Timeout Page: Cvent can redirect SSO users to a predefined timeout page if their browser sessions expire. Clients must provide Cvent with a link to the page that users will be redirected to when such a timeout happens. Custom Header Image By default, the Cvent header image will be displayed on all static HTML and error pages. If a client would like to customize this header, a URL of an image must be provided during SSO configuration. Recommended Size: 800 px x 90 px is the standard size recommended for a custom header. Restrictions: The header images cannot be written in JavaScript or contained in a Flash file. 17

18 Implementation Options You will also need to choose the following for your configuration: SSO Solution: SAML 1.1 or 2.0 Client Public Encryption Key: SHA-1 or SHA-256 Cvent Login Page: Disable the Cvent login page or keep it active Certificate Name: Only needed if you are using multiple certificates SSO Solution The Cvent application supports two types of standard SSO solutions: SAML 1.1 SAML 2.0 Each solution has a different way of determining the origin of the SSO message and acquiring the user s identification. SAML 1.1 and SAML 2.0 are incompatible with each other and use different processes for authentication. Refer to the appropriate procedure in this guide when beginning the configuration process. NOTE Cvent Login Page You have the option to disable Cvent s login page for your account. Disabling the login page will turn off your ability to manage passwords for users. Upon creating a new user, the administrator will not have to enter and confirm a password. Disabling Cvent s login page applies to users on the backend of Cvent s application. Passwords for meeting request users will still function the same way. NOTE Certificate Name Cvent supports multiple public keys for a single Cvent account. You will need to assign a name to each certificate and send an issuer attribute within each SAML assertion dictating which certificate you would like to use. The format of the issue field should be similar to: <saml:issuer> 18

19 User Interface (UI) Changes Once you have configured SSO, there will be changes made to your password rights as well as your users rights for adding and editing. Disabled Passwords If the Cvent login page has been turned off: All password functionalities will be disabled. Users logging in will never be prompted for a password change. Federated SSO vs. Direct SSO If the client SSO configuration calls for a Federated ID type: Administrators will be able to use the application to add and edit the Linked IDs of the account s other users. The required text must be entered in the Federated ID field on the User Information page. This text field will only appear after the account has been configured for SSO with a federated user ID type. A user cannot edit their own Federated ID value in Cvent; another administrator must edit this value on that user s behalf. NOTE If the client SSO configuration calls for a Direct type, users will not be able to change their usernames at any given time. Administrators will be the only ones given permission to change other usernames. Any discrepancy between usernames will result in access to the application being denied. WARNING 19

20 Authentication Procedure For the purpose of receiving the SAML assertion message, two pages have been created at the following dynamic URLs: To authenticate application users: Note: The account stub is a 36-character GUID. This can only be provided by Cvent. To authenticate meeting request users: Note: The endpoint will vary depending on your SSO use case. Refer to the sections near the beginning of the guide for information about each use case. Your account identifier, which must be embedded into the dynamic URL, will be provided at the time of configuration. A target URL must be provided in the query string for any user authenticating to a meeting request form or site. To authenticate a user in the Cvent system, a valid SAML token must be submitted through a HTTP POST form via the user s browser to one of the above URLs. The name of the POST form field must be SAMLResponse. SAML 1.1 Standard The message will contain a protocol structure similar to the following, contained within a SOAP envelope: <samlp:response xmlns:samlp= urn:oasis:names:tc:saml:1.0:protocol MajorVersion= 1 MinorVersion= 1 ResponseID= (RESPONSE_ID) InResponseTo= (MESSAGE_ID) IssueInstant= (TIMESTAMP) > <! Signature > <! Assertions and Statements > </samlp:response> Within this protocol, there will be a standard XML signature as well as an assertion that contains authentication information and the identity of the user. The XML signature must be generated using the private key from the public/private key pair, as previously noted in the Configuration Requirements section. 20

21 The identity assertion within the <Response> message should look similar to this: <Assertion AssertionID= (ASSERTION_ID) IssueInstant= (TIMESTAMP) Issuer= (IDP_ID) MajorVersion= 1 MinorVersion= 1 xmlns= urn:oasis:names:tc:saml:1.0:assertion xmlns:xsd= xmlns:xsi= > <Conditions NotBefore= T00:46:02Z NotOnOrAfter= T00:51:02Z > <AudienceRestrictionCondition> <Audience>(SP_BASE_URL)</Audience> </AudienceRestrictionCondition> </Conditions> <AuthenticationStatement AuthenticationInstant= (ASSERTION_TIME) AuthenticationMethod= urn:oasis:names:tc:saml:1.0:am:password > <Subject> <NameIdentifier Format= urn:oasis:names:tc:saml:1.1:nameid-format: address > (LOCAL_ACCOUNT_ID) </NameIdentifier> <SubjectConfirmation> <ConfirmationMethod> urn:oasis:names:tc:saml:1.0:cm:bearer </ConfirmationMethod> </SubjectConfirmation> </Subject> <SubjectLocality IPAddress= /> </AuthenticationStatement> <ds:signature><! Signature (if assertion is signed) ></ds:signature> </Assertion> 21

22 SAML 2.0 Standard The protocol structure of this newer SAML 2.0 Standard will be similar to SAML 1.1 Standard. <samlp:response xmlns:samlp= urn:oasis:names:tc:saml:2.0:protocol ID= (RESPONSE_ID) InResponseTo= (MESSAGE_ID) Version= 2.0 IssueInstant= (TIMESTAMP) Destination= (DESTINATION_URL) > <! Signature > <! Assertions and Statements > </samlp:response> However, the structure of the assertion within this protocol will hold some key differences from SAML 1.1 Standard. The following is an example of what an SAML 2.0 Identity Assertion may look like: <saml:assertion xmlns:saml= urn:oasis:names:tc:saml:2.0:assertion Version= 2.0 ID= (ASSERTION_ID) > <saml:issuer>(idp_id)</saml:issuer> <ds:signature><! Signature (if assertion is signed) ></ds:signature> <saml:authnstatement AuthnInstant= (ASSERTION_TIME) SessionIndex= > <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:password </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:subject> <saml:nameid>(local_account_id)</saml:nameid> </saml:subject> <saml:audiencerestriction> <saml:audience>(sp_base_url)</saml:audience> </saml:audiencerestriction> </saml:assertion> 22