If your organization has your own login mechanism (i.e. people already have a user/password on your organization's computer systems), you may be able to set up Grenadine to accept logins via your own mechanism.

Some organizations have existing websites or internal computer systems that are used by their members to manage their accounts. Your members may already have login credentials, and you want them to be able to use these same login credentials when registering, purchasing tickets, or setting up their event profile within Grenadine websites.

If your login mechanism supports oauth, Grenadine can set up your event manager to connect to your authentication provider. This will enable your user to use the same user/password on Grenadine websites as they do when logging in to your own corporate systems.

If your authentication provider supplies metadata (such as an employee number, student number, member number), Grenadine may also be able to fetch those metadata at login time, to insert into a metadata field of the person profile.

How it works

By default, Grenadine offers several ways to attendees and speakers to identify yourself. These include:

  • Login with Facebook
  • Login with Google
  • Login with LinkedIn
  • Login with Grenadine email/password

When we set up your custom login provider, your organization’s login will be presented as an additional choice when people wish to log in. For example, here is a screenshot of an event website that allows for Facebook, Google, and Grenadine login, in addition to a university’s custom login provider (Concordia University in this example):

Note that in the Grenadine checkout configuration screen (available in the Tickets -> Configure checkout process page), you can choose which login mechanisms you wish to enable, and which you wish to disable. Therefore, you could decide to enable only your own login mechanism and disable all other options.

What information we need from you

If your environment has an OAuth2 provider for authentication it is possible to integrate that with Grenadine so that people using the generated sites can log in with their credentials from your system.

There may be some differences between OAuth providers in the names and types of parameters used when configuring them. You will need to coordinate with the Grenadine development team to set up your OAuth login.

To enable this you will need to coordinate with our development team. The information that we would need consists of the following:

Endpoint This the URL for your OAuth server
Key/ClientId A key for our application when accessing your OAuth server
Secret The secret for our application
Scopes (if applicable) If any OAuth scopes are applicable

Grenadine will also pass a state parameter when initiating the OAuth request we expect this state parameter to be returned to us as per the OAuth2 specification.

Often the OAuth server needs to know the origin and redirect endpoints.

  Authorized Origin Authorized Redirect
staging https://sites.staging.grenadine.co https://sites.staging.grenadine.co/sites/auth/{service_name}/callback
production https://sites.grenadine.co https://sites.grenadine.co/sites/auth/{service_name}/callback

As well as passing back the authentication and refresh tokens in the response. The Authhash will return the following:

  • provider the name of the provider as a single string (usually the same as {service_name})
  • uid the UID for the person logging in in your system

The info hash returned from the provider should contain the following variables:

  • first_name the first name of the person logging in
  • last_name the last name of the person logging in
  • email the email of the person logging in

and optionally:

  • image the image of the person logged in (this would be a public URL to an image)
  • name the full display name of the person logged in
Tags: enterprise-edition configuration login