Overview: Identity

Application Description

Aspenware Identity is a separately licensed web application that is leveraged by Aspenware Commerce, Aspenware Arrival, and can be utilized by other 3rd party applications (such as a mobile resort app) as the authentication platform, enabling a single login (SSO) across various applications. Aspenware Identity integrates with resort POS and guest engagement points to provide single sign-on and secure access to data.

Aspenware Identity maintains user accounts across various applications to ensure that the “Mikaela S.” in the POS is the same person as the “Mikaela S.” in the mobile app and that Mikaela has a streamlined and personalized experience across all the places she interacts with the resort brand online. Aspenware Identity is already supported with the Wearlynx and Spotlio mobile apps. Identity can easily be integrated into other sites and apps using our technical integration documentation.

Open

When an application is configured to use Identity, guests are temporarily routed from the application upon selecting “Sign In/Create Account” to Identity to facilitate logging in. This identity flow is hosted on an alias such as login.resortname.com. Once logged in, Identity returns users to the original application, such as Aspenware Commerce, as a logged-in customer. Aspenware Identity is built using the OpenID Connect industry standard and OAuth2.0 for enhanced security, allowing applications to confirm a guest’s identity in a secure manner and also obtain basic profile information about the guest and their household to provide a personalized experience in the connected application(s).

While Aspenware Arrival requires Identity to be leveraged for authentication, Aspenware Commerce and resort mobile apps can optionally use Identity for authentication. Once Identity is set up and configured, turning on Identity for Aspenware Commerce is enabled through installing a plugin and updating several settings within the Commerce platform. Benefits to using Identity for Commerce authentication rather than native Commerce authentication include:

• Implicit find me flows are more likely to catch guests who already have accounts, routing them to find their accounts, thereby decreasing duplicate customers in the POS.

• Seamless navigation between applications if multiple applications use Identity as an authentication platform. For example, a guest who is logged in to Aspenware Arrival will also be logged in to Aspenware Commerce and the mobile app.

• Required password resets offer a more secure environment than standard login as Identity can require guests to reset their password if the password change date in the POS is after today’s date.

Claim Account Flow Enhanced with Identity

Identity supports the same functionality as standard Commerce Login, including allowing guests to log in (using email, username, or pass id), reset password, create a new account, and claim an existing account (called Find My Account in Commerce). While “Claim Account” is supported in Identity, the user experience to “claim account” is a different user experience from the native Aspenware Commerce authentication flow, where a guest selects “Find My Account” to claim an existing account.

Open

Figure A: Standard Login

Figure A demonstrates how guests are prompted to claim an account in the native Commerce authentication flow, which is different from the Claim Account flow in Identity.

Figure B demonstrates how guests are prompted to claim an account in the Aspenware Identity authentication flow, which is different from the Claim Account flow in the native Commerce authentication flow. Identity uses implicit find me.

Guests would be prompted to claim their account in the following circumstances.

When a customer who is eligible to claim account logs in…

A guest attempting to login will be routed down claim account flows in the following scenarios - View full login flow diagrams

• Scenario 1: Guest enters an email that does NOT have an authentication profile associated, but DOES match a contact’s email profile in resort POS and also has no other contacts that share that email profile. (This replaces “Find me by Email” in native Commerce authentication.)

• Scenario 2: Guest enters a pass ID that does NOT have an authentication profile associated, but DOES match a contact in resort POS. (This replaces “Find me by Pass Number” in native Commerce authentication.)

When a customer who is eligible to claim an account creates an account…

A guest attempting to create an account will be routed down claim account flows in the following scenarios - View full create account flow diagrams

• Scenario 1: Guest enters an email that does NOT have authentication profile associated but DOES match a contact’s email profile in resort POS and also Contact First and Last Name (This replaces “Find me by Email” in native Commerce authentication.)

• Scenario 2: Guest enters an email that does NOT have authentication profile associated but DOES match a contact’s first name, last name, date of birth, and zip code (This replaces “Find Me by Personal Information” in native Commerce authentication.)

How Guest Checkout in Aspenware Commerce works with Identity

Guest checkout compatibility is available with Identity 2.4 or later for resorts using RTP|ONE. If enabled in Aspenware Commerce, guests selecting “guest checkout” prior to completing their order are routed to a simple registration form. Once registered, these customer records are created in RTP|ONE with a specific IPTypeCode (configurable) including email profile, but no authentication profile. Guests and any additional members created and assigned during this checkout workflow also show in RTP|ONE with this specific IPTypeCode. If a guest decides to return to the store and check out as a guest again, another profile will be created in accordance with the guest’s selection. If the birth date, phone, or any other guest profile information are collected as part of guest transactions these will also be added to the customer record in RTP|ONE. If a guest decides to return to the store and selects to authenticate, a prior guest account can be converted to an authenticated account when the guest steps through the claim account flow in Identity, detailed above. The guest registration screen is not hosted in Identity, however, when a guest selects to or is required to authenticate in a subsequent purchase, Identity powers their sign-in experience.

Force Password Reset within Identity

Aspenware Identity optionally allows resorts to manage when users are required to reset their passwords by utilizing the password expiration date field in RTP|ONE combined with Identity settings. Upon login, guests who have an expired password will be notified that they need to reset their password and will be directed to a password reset email. The password reset email will direct guests through the password reset flow and then back to the login page where they will be able to log in using their new password. Guests whose passwords have not expired will be able to log in (and/or reset their password) through the existing flows.

Account Lockout within Identity

Identity now supports defining the number of failed login attempts a lockout is enforced after and the lockout length.

Opt-In/Out of Marketing Communications within Identity

Aspenware now supports optionally enabling customers to opt-in or out of marketing communications when creating an account through Identity. This feature flags the customer’s communication profile in RTP|One, which is used by email marketing providers to decide who is signed up to receive marketing emails.

Google reCAPTCHA with Identity

Google reCAPTCHA v3 API helps your resort detect abusive traffic without user interaction.

3rd Party Developers Integrating Aspenware Identity

If integrating Aspenware Identity with a 3rd party application, Aspenware will partner with application developers for the integration implementation. Our developer documentation for 3rd party developers is available here: https://developer.aspenware.net/identity/#aspenware-identity-server. Keep in mind that many of the settings, language strings, theme requests, and more are customizable per application (or client) integrating into the single Identity server. It is possible to have unique content viewable when a guest comes to Identity through the resort’s mobile app that is different content from what they see when they come to Identity through Commerce.