This document serves as a reference, not a comprehensive tutorial. Please contact your KT implementations team or account manager if you would like further guidance.
Single sign-on presents Key Travel as a SAML 2.0 Service Provider via an HTTP Redirect binding. This is the most common form of the SAML protocol, and is supported out of the box with most identity provider software.
To get started with single sign-on, please contact us with the URL to your identity provider metadata. We will then use this to configure our service provider, which will then accept login requests for your SAML entity.
You may need the following information to configure your identity provider for Key Travel:
| Entity ID | https://sp.keytravel.com/oa/metadata |
|---|---|
| SAML Metadata | Always available at https://sp.keytravel.com/oa/metadata |
| Logon endpoint | Varies; see below |
| SAML response postback URL (AssertionConsumerServiceURL) | https://sp.keytravel.com/oa/auth/rcv/saml2/post |
Note that you will still need to provide data feeds for configuring departments and access permissions, regardless of whether you use single sign-on or not, or successfully authenticated users will not be able to do anything useful with their login session.
All user journeys must start at a Key Travel-specific URL, which will redirect the user back to you with a valid SAML request. You can place a link to this URL on your internal portal, which will land users straight into a login flow. Alternatively, if a user visits https://my.keytravel.com directly, we will infer you as the identity provider from the user's email address, and redirect them ourselves.
The starting URL is partly derived from your identity provider ID. You can calculate it below:
| Paste your identity provider ID here | Direct users to this link to log in |
|---|---|
| Click the link to test it. | |
| This calculation is performed in-browser. Nothing you type here is sent to Key Travel. | |
Single sign-on at Key Travel uses the following attributes (some systems call these claims):
| Purpose |
Attribute name
We support both OID and XML Schema forms for most attributes. Select the one that works best with your existing configuration. |
Required? | Guideline |
|---|---|---|---|
| Email address |
Any one of the following:
|
Required | The email address of the user logging in. This uniquely identifies the user to Key Travel. |
| First name |
Any one of the following:
|
Required | The user's first name. |
| Last name |
Any one of the following:
|
Required | The user's last name, or surname. |
| Job title |
Any one of the following:
|
Not required | The user's job title, also known as their role. |
| Person title |
|
Not required | The user's personal title, also known as salutation. |
| Request scope |
Any one of the following:
|
Depends on your configuration | Unless advised otherwise, do not include this attribute. |
| Please contact us if you have different attribute requirements. We may be able to match your existing configuration. | |||
Best practices dictate that cryptographic keys should be rotated regularly, so your signature key most likely has an expiration date. If this date is approaching, please contact us with an updated metadata document and we will agree on a switchover date.