Concur Technologies, Inc.

Security Assertion Markup

Language (SAML)
SSO Solutions for Concur Travel & Expense

Last Revised: April 12 2017

Proprietary Statement

This document contains proprietary information and data that is the exclusive
property of Concur Technologies, Inc., Redmond, Washington. No part of this
document may be reproduced, transmitted, stored in a retrieval system, translated
into any language, or otherwise used in any form or by any means, electronic or
mechanical, for any purpose, without the prior consent of Concur Technologies, Inc.

The information contained in this document is subject to change without notice.

Accordingly, Concur Technologies, Inc. disclaims any warranties, express or implied,
with respect to the information contained in this document, and assumes no liability
for damages incurred directly or indirectly from any error, omission, or discrepancy
between any Concur Technologies, Inc. product or service and the information
contained in this document.

© 2004 - 2017 Concur Technologies Inc. All rights reserved.

Concur® Expense, Concur®, and their respective logos are all trademarks of Concur
Technologies, Inc. All other company and product names are the property of their
respective owners.

Published by Concur Technologies, Inc.

601 108th Ave NE
Bellevue, WA 98004

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Table of Contents

SAML Overview ...........................................................................................18

Purpose ...................................................................................................... 18
SAML Overview ........................................................................................... 18
Benefits of SAML ......................................................................................... 19
Who Should Use SAML? ................................................................................ 19

Chapter 1: SAML Posting Process Overview ................................................20

SAML Posting Process Overview ..................................................................... 20

Chapter 2: SAML Entity Configurations and Decisions .................................22

Industry-Standard SAML .............................................................................. 22
Service Provider MetaData ............................................................................ 26
SAML Assertion ........................................................................................... 26
SAML ASSERTION Example ...................................................................... 27
ASSERTION CONSUMER SERVICE (ACS) URL ............................................ 28
SAML 2.0 ............................................................................................... 29
Login ID ................................................................................................ 29
Key Rotation .......................................................................................... 29
Email Handling ....................................................................................... 30
Conclusion ............................................................................................. 30
Concur for Mobile – Single Sign-On (SSO) ...................................................... 31
Overview ............................................................................................... 31
Who should use SSO with Concur Mobile? .................................................. 31
Configuration ......................................................................................... 31
Mobile SSO Required .......................................................................... 32
Mobile SSO URL................................................................................. 32
What the User Sees in Concur Travel & Expense .............................................. 32
Email .................................................................................................... 34
What the User Sees on Mobile .................................................................. 35
iPhone .............................................................................................. 35
Android ............................................................................................ 35
Mobile SSO Enforced ............................................................................... 36
iPhone .............................................................................................. 36
Android ............................................................................................ 36
**Optional** Mobile SSO Enforced or not Enforced ..................................... 37
Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 iPhone .............................................................................................. 37
Android ............................................................................................ 38
SSO on the BlackBerry ............................................................................ 38
Use Cases .............................................................................................. 39
Install .............................................................................................. 39
Initial Login ...................................................................................... 39
Subsequent Login .............................................................................. 40
Company Session Expires ................................................................... 40
Logout ............................................................................................. 41
Clear Cache ...................................................................................... 42
Remote Wipe .................................................................................... 43
Flow Charts............................................................................................ 44

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
SAML Overview

Purpose
This document contains information necessary for clients to understand the use of a
Security Assertion Markup Language (SAML) solution for single sign-on (SSO) in the
Concur Travel and Expense Platform (CTE). Included is a definition of SAML, how
SAML enables single sign-on, and what requirements are needed by the client and
Concur in order to implement them within the Concur Travel and Expense Platform
(CTE).

SAML Overview
This document contains information necessary for clients to understand the use of a
Security Assertion Markup Language (SAML) solution for single sign-on (SSO) in the
Concur Travel and Expense Platform (CTE) and Concur Native Mobile application.
Included is a definition of SAML, how SAML enables single sign-on, and what
requirements are needed by the client and Concur in order to implement them within
the Concur Travel and Expense Platform (CTE) and Concur Native Mobile application.

Security Assertion Markup Language (SAML) is an open standard for exchanging

authentication and authorization data reliably between an identity provider (client
portal) and a service provider (Concur Technologies) even though the identity
provider and the service provider may be using different authentication products.
Specifically, SAML defines how the XML is formatted, encoded, passed through the
Internet, decoded and validated. SAML was developed by the Organization for the
Advancement of Structured Information Standards (OASIS), as a way to allow
systems to identify valid users.

SAML helps reduce time wasted when users must sign on multiple times to access a
suite of tools. The waste reduction is accomplished through single sign-on (SSO).
SSO provides a protocol for end users to authenticate once with an identity provider,
and upon successful authentication, access multiple tools or Web sites. In the case of
Concur Travel and Expense Platform (CTE), once a user is logged on to their
workstation or Corporate Portal, the user does not have to log on again to CTE. CTE
recognizes the employee and bypasses the Log On page; instead, it displays the My
Concur page (by default).

SAML uses existing HTTPS protocols to transfer assertions across the Internet using
XML. When data is transferred between two security domains, it is encoded and
encrypted (HTTPS) to ensure that it cannot be manipulated or read if intercepted by
a third party.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Benefits of SAML
SAML is the standard for SSO across the Internet. Most SSO vendors now conform to
this standard because of its ease of integration and improvement of online
experience for the end users as well as the following benefits. SAML has the following
properties:
 It is platform neutral and does not require particular platform architecture or
vendor implementations. Many of its implementations have demonstrated
successful interoperability.
 It promotes an improved online experience because it allows users to
authenticate at an identity provider once and then have access to service
provider software without any additional authentication.
 Combined with HTTPS, SAML is a secure method of transferring information
across the open Internet.
 Successful implementation of SAML using multiple products, including: Ping,
Okta, Centrify, Azure & OneLogin

Who Should Use SAML?

In general, the SAML solution should be employed by sites whose enterprise has a
SAML-based Identity solution and manages their users in a centralized master
Directory. Otherwise, a different solution may be required.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Chapter 1: SAML Posting Process
Overview

SAML Posting Process Overview

Identity Provider (IDP) Initiated (Client Server)

IdP Initiated: The user is accessing resources on the Identity Provider, and wishes
to access resources on another web site (the Service Provider). The user already has
a current security context with the Identity Provider. A SAML assertion is provided to
the Service Provider.

1. At some point the user will have been challenged to supply their credentials
to the site IDP sign in or behind the scene authentication (using Kerberos for
example).

2. The user successfully provides their credentials and has a security context
with the Identity Provider session.

3. The user selects a menu options, link, or function on the resource that means
the user’s wants to access a resource or application on another web site.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 4. The IdP sends a HTML form back to the browser. The HTML FORM contains a
SAML response, within which is a SAML assertion. The SAML specifications
mandate that the response must be digitally signed. The HTML FORM will
contain an input or submit action that will result in a HTTP POST.

5. The Browser, either due to a user action or via an “auto-submit” issues a

HTTP POST containing the SAML response to be sent to the Service Provider
Assertion Consumer Service

6. The Service Provider’s Assertion Consumer validates the digital signature on

the SAML Response. An access check is then made to establish whether the
users has the correct authorization to access the target site. If this validates
correctly, it sends a HTTPS redirect to the browser to the resource.

If the user credentials are validated, the following actions can occur:
 The user's browser is automatically authenticated into the Concur Travel and
Expense Service, opening the My Concur screen.
 If the client has provided a valid Authorization Decision statement or
“RelayState” value indicating a different screen than this, the user is
redirected to the specified screen.
 If the credentials cannot be validated, the user’s browser is redirected to an
error URL provided by the client or to the default Login Screen if an error URL
is not provided in the SAML Response.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Chapter 2: SAML Entity Configurations
and Decisions

Industry-Standard SAML
The industry-standard SAML solution requires the exchange of configuration
information between the client and Concur to grant access to CTE. The following
information is given by the client to the Technical Consultant (TC).

The table below is a list of configurations and decisions followed by the designated
decision maker and implementer.

Table 1: Industry-standard SAML Configuration Requirements

Configuration Description Decided Client to Implemented
Detail by provide by
Concur

Identify Refer to the SAML Client Concur Logon Concur

Information Assertion section of this ID
chapter for more
information.

Encoding If the client is using Client Notification Concur

Method industry standard SAML, that digital
the method will be digital signatures are
signatures. being used

Signature The RSA Digital Signature Client What Concur and

Algorithm Algorithm is Supported signature Client
algorithm is
being used

Public Key Client’s Public Signature Client A Public key, Concur and
Key provided in a Client
.cert file or a
Base-64
.X509 text file

Time Out The timeout method Client Notification of Concur

Method defines the window of time timeout
that a given assertion is method being
valid. Just as for Concur used
SAML, there are two
timeout methods that the
client my choose from:
saml:condition
(conditional) or
saml:authentication
(instant). For more details
see the Time Out Method
section for Concur SAML.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 Time Out If the client decides to use Client Timeout value Concur
Value the authentication instant in seconds
timeout method, they must (Used only
provide Concur a timeout with
value in seconds. Authentication
Instant
timeout
method)

Error Redirect An error redirect is a URL Client URL to Concur and

URL value provided and Redirect the Client
maintained by the client User’s
that redirects the user’s Browser Upon
browser in the event of an Authentication
authentication error. Error.
Failure to provide the URL
results in a default page Optional.
for authentication errors
provided by Concur.

The client can decide to

instead specify the URL
within the nested element
called
<concursaml:OnError>
that specifies the error
return URL. This element
requires that the
concursaml namespace be
added to the
<saml:Assertion>
document. The example
below shows the redirect
to a custom URL:
<saml:Advice
xmlns:concursaml="<BASE
URL>
/SAMLRedirector/ClientS
AMLLogin.aspx">

<concursaml:OnError>htt
p://news.google.com</co
ncursaml:OnError>

</saml:Advice>

IMPORTANT NOTE: This

redirect URL must not be
the URL that generates the
SAML assertion and posts
it to Concur. Using the
same URL for both the
redirect and the SAML
assertion may cause an
infinite loop if there is any
problem with the
authentication.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 Enforce SSO Enables the client to Client Notification Concur
(Optional) enforce single sign-on. If that SSO
SSO is enforced, all users should be
must use it to enter Concur enforced.
Travel and Expense. (Optional)

Start Date Optionally used to indicate Client Notification of Concur

(Optional) what date and time a new the start date
configuration should take for the given
effect. This date allows for key.
rolling keys. (Optional)

Home Page Client The value to Concur

Option (HPO) SAML SSO Documents insert for
Value posted to Concur can HPO_VALUE is
include information that CES
indicates the landing page
on which the end user will
arrive and the particular
Report or Request to
display. This information is
specified in Authorization
Decision Statement
elements defined by the
SAML specification and
takes the form below.
Alternatively, this
information can be
provided through the
RelayState (examples
referenced below).
In order to display a
particular Report or
Request on the landing
page, the client’s SAML
infrastructure must pass
the value of the “cte” CGI
parameter.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 SAML 1.x
<saml:Assertion>

….

<saml:AuthorizationDeci
sionStatement
Resource=”XXXX”>

<saml:Action>HPO_VALUE<
/saml:Action>

<saml:AuthorizationDeci
sionStatement>

SAML 2.x
<saml:Assertion>

...

<saml:AuthzDecisionStat
ement Resource=”XXXX”>

<saml:Action>HPO_VALUE<
/saml:Action>
</saml:AuthzDecision
Statement>

RelayState

Provided to the ACS URL

path (inline URL encoded)

/SAMLRedirector/ClientS
AMLLogin.aspx?relaystat
e=hpo%3D4%26cte%3D<valu
e of “cte” parameter
from the e-mail
notification>

Provided to the Page

Response Object (next to
SAML Response)

RelayState=https://www.
concursolutions.com?hpo
=4&cte=<value of “cte”
parameter from the e-
mail notification>

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Service Provider MetaData
Concur does not publish a metadata file or XML as the Service Provider. However,
the below metadata XML can be used if your IDP requires the metadata XML. You will
need to get the <BASE_URL> from your Technical Consultant:
<EntityDescriptor entityID="https://---<BASE_URL>---"
xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress</NameIDFormat>
<AssertionConsumerService index="1"
Binding="urn:oasis:names:tc:SAML:1.1:bindings:HTTP-POST"
Location="https://---<BASE_URL--->/SAMLRedirector/ClientSAMLLogin.aspx"/>
</SPSSODescriptor>
</EntityDescriptor>

SAML Assertion
Included is an example of an assertion for IDP Init SAML. It contains a number of
important elements including a Digital signature and Name identifier. These elements
must be provided to Concur before implementation. In addition, note that:

1. Reference URI=“” attribute of the reference block ds (digital signature). It is a

reference tag pointing to the XML block that has been signed. If the tag is
empty, it is assumed that the entire block is being signed.

2. The SAML namespace is defined by the spec version. ("1.0" will be used
throughout this section as an example.)

3. The AuthenticationMethod value should be any of the values defined in the

SAML specifications. An example is:
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password".

The user ID within the NameIdentifier element, described above, can be combined
with the Issuer element (SAML 2.0) or attribute (SAML 1.1) that is part of the
Assertion element to form a unique user ID. The software will automatically insert
the "@" character between the user Id and the issuer.

In this example the generated user ID will be [email protected]

Using SAML 1.1:

<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.0:assertion#WindowsQualifiedDomainName"
NameQualifier="dc=us,dc=uat,dc=Client,dc=net">u200654</saml:Name Identifier>

<saml:Assertion AssertionID="FEMNhW3zeee6JAF295Nw==" IssueInstant="2005-08-

23T01:26:55Z" Issuer="idmsamuat.The Client.net" MajorVersion="1"
MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
USING SAML 2.0:

<saml:Assertion AssertionID="FEMNhW3zeee6JAF295Nw==" IssueInstant="2005-08-

23T01:26:55Z" MajorVersion="1" MinorVersion="0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<saml:Issuer>idmsamuat.TheClient.net</saml:Issuer>

SAML ASSERTION Example

<samlp:Response ID="---"
Version="2.0"
IssueInstant="2016-05-25T14:38:05.101Z"

Destination="https://<BASE_URL>/SAMLRedirector/ClientSAMLLogin.aspx"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">---ISSUER VALUE -----
</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="-----"
IssueInstant="2016-05-25T14:38:05.070Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>---ISSUER VALUE -----</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#-----">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-
exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>--------</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>---------</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>-----x509 cert key -------
</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">----FULL NAME ID VALUE-----</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2016-05-25T14:43:05.070Z"

Recipient="https://<BASE_URL>/SAMLRedirector/ClientSAMLLogin.aspx"/>
</SubjectConfirmation>

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 </Subject>
<Conditions NotBefore="2016-05-25T14:33:05.070Z"
NotOnOrAfter="2016-05-25T15:33:05.070Z"
>
<AudienceRestriction>
<Audience>https://www.concursolutions.com</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2016-05-25T14:37:23.768Z"
SessionIndex="------">
<AuthnContext>

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnCont
extClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

! It is strongly recommended that the public key and private key originate from a
certificate issued by a Trusted certificate authority. Concur Implementation must
work directly with the client if they intend on using a client-generated certificate
in lieu of that issued by the Trusted certificate authority.

NOTE: SAML 1.1 and 2.0 is available for SSO into CTE. In addition, Concur is
compatible with all SAML specifications but is not compliant. This means that
Concur handles many SAML features and functionality but not all of them.

ASSERTION CONSUMER SERVICE (ACS) URL

For Industry Standard SAML, the Enterprise directory tool should be configured to
post the SAML document. Your Concur Technical Consultant will provide you the ACS
URL to be posted to Concur using TLS (https).

In addition to the URL there are 2 additional parameters that can be used for a
secondary SSO or a partner SSO configuration.

Below is an additional value that can be setup with your Technical Consultant to
allow for an additional configuration. This commonly used for cutting over to a new
SAML configuration. Please consult with your Technical Consultant on the best
strategy and use for this feature.

Note: The Concur Mobile SSO can only have one IDP Sign-In page
configured at time.

Secondary SSO configuration path example:

https://---<BASE_URL--->/SAMLRedirector/ClientSAMLLogin.aspx?p=sso2

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
SAML 2.0

SAML SSO for Concur Travel and Expense supports the SAML 1.1 and 2.0
specifications.

Login ID

Concur can resolve the user login ID in two ways. The full login ID with domain can
be in the NameIdentifier (SAML 2.0: NameID) element of the assertion XML.

<saml:NameID
Format="urn:oasis:names:tc:SAML:1.0:assertion#WindowsQualifiedDomainName"
NameQualifier="dc=us,dc=uat,dc=Client,dc=net">[email protected]</
saml:NameID>

In cases where the domain is not a part of the field used to create the login id the
domain can be in the Issuer element and the system will concatenate the values
together.

Using SAML 1.1

<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.0:assertion#WindowsQualifiedDomainName"
NameQualifier="dc=us,dc=uat,dc=Client,dc=net">u200654</saml:Name Identifier>

<saml:Assertion AssertionID="FEMNhW3zeee6JAF295Nw==" IssueInstant="2005-08-

23T01:26:55Z" Issuer="idmsamuat.The Client.net" MajorVersion="1"
MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

Using SAML 2.0

<saml:NameID
Format="urn:oasis:names:tc:SAML:1.0:assertion#WindowsQualifiedDomainNam
e"
NameQualifier="dc=us,dc=uat,dc=Client,dc=net">USER</saml:NameIdentifier
>

<saml:Issuer>COMPANYDOMAIN.COM</saml:Issuer>

NOTE: The following characters cannot be included in any login: % [ ' # ! * & ( ) ~ ` {
^}\|/?><,;:"+=]

Key Rotation

Key rotation is the introduction of a new key by the client. Typically key rotation is
seamless, and the coordination between client and Concur Support ensures a
seamless transition, without problems of validation. If you need to rotate or update
your signing key, contact your Authorized Support Contact to open a case with
Concur Support and Support Representative will coordinate and assist with this
change.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Email Handling

Emails coming from the Concur system contain links that provide a quick short cut
into the application. An example of this is expense report approval email for
managers which is configured in Policies in Expense Administration. These emails
contain a link that once clicked on by the end user will launch the user’s browser and
after login will display the expense approval screen with the specific expense report
requiring approval automatically selected. The approving manager is one click from
approving the report.

With SAML SSO, additional changes to the client's SAML infrastructure are required
to enable these links. These changes require reading parameters in the URL that is
sent to the client’s SAML infrastructure. The URL will contain two CGI parameters:
 hpo
 cte

These parameters must be read and used in the construction of the

AuthorizationDecisionStatement or RelayState as described in detail in previous
chapters.

Conclusion

In today’s industry, issues of privacy and identity management are of highest

importance to service providers and clients who exchange confidential information.
By providing a standard for exchanging authentication information, SAML gives a
federated solution for identity management. In addition to providing security, SAML
is platform neutral, and increases end user satisfaction by decreasing the amount of
time users spend logging on to a host of applications.

It is important to note that industry standard SAML requires unique components

prior to implementation. By becoming familiar with these components, the client can
make decisions quickly and provide the correct information to Concur in order to
begin the implementation process.

While SAML has many benefits, and is easy to integrate, it is also a defined by a
relatively complex process. In order to make an informed decision about how to
implement, it may be useful to read more about the SAML Standards on the Web site
for Organization for the Advancement of Structured information Standards (OASIS)
https://www.oasis-open.org/.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Concur for Mobile – Single Sign-On (SSO)

Overview

Clients can use Concur for Mobile Single Sign-On (SAML SSO) for mobile login. By
using SSO, users can log in to the mobile device using their regular corporate login
and password instead of having a separate one for the mobile device. Clients must
have enabled SAML SSO for Concur Travel & Expense.

! If a client configures Mobile for SSO and SSO is required, then all of the client's
mobile users must log in using SSO.

If a client configures Mobile for SSO but SSO is not required, then the client's mobile
users can log in using SSO or their mobile-only password (PIN).

NOTE: If SSO is not required, the SSO login option appears but the user can enter
his/her email address or Concur username (from the web version of Concur)
and will then be directed to use his/her mobile-only password (PIN).

The login page must use Forms Based Authentication.

Who should use SSO with Concur Mobile?

Concur for Mobile already provides exceptional security features – So why add
SSO?

Concur added SSO functionality in response to customer feedback and requests. It

provides a way to ensure that the mobile app fits into corporate security policies by
laying the authentication burden on the corporate network as opposed to Concur.
Several examples of where SSO on Concur for Mobile can provide additional
authentication options that the standard application cannot:
 Source IP tracking of where users are connecting from
 User control to allow only authorized users to use the mobile app
 Basic device control to block connections from certain devices that might not
be corporately issued
 User access logging

Configuration

 For clients who want to use SSO:

1. Clients must first implement CTE SAML SSO.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 2. Next, clients must develop their company’s mobile-optimized network login
site.

BEST PRACTICE

Concur encourages simplicity – logo, User Name field, Password field,

Login button. Clients can refer to the following sites for more information.
 http://mobile-patterns.com
 http://www.noupe.com/how-tos/mobile-web-design-tips-and-best-
practices.html

Then, clients must contact Concur Client Support to:

 Provide Concur with the URL for the company’s mobile-optimized network
login site.
 Set the appropriate module properties.

NOTE: For BES (Blackberry Enterprise Servers) companies, the policy for Cookies
Support must be set to OFF (more information at
http://docs.blackberry.com/en/admin/deliverables/14334/Configure_MDSCS_
manages_HTTP_cookie_storage_490054_11.jsp).

To implement Mobile SSO, Concur sets two module properties:

Mobile SSO Required

 If this option is set to true, then all of the client's mobile users must log in
with SSO.
 If this option is set to false, then the client's mobile users can log in with SSO
or their mobile-only password (PIN).

NOTE: The user enters their email address or web-version Concur username and
then is directed to use their mobile-only password (PIN).

Mobile SSO URL

 This is the company’s mobile-optimized network login site.
 This will change the Mobile Registration page in Profile (shown below).

What the User Sees in Concur Travel & Expense

For clients who use SSO, all references to login and mobile-only password (PIN)
creation will be removed from the Mobile Registration page in Profile. Instead of the
Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
login and mobile-only password (PIN), the Mobile Registration page provides a
Company Code that users must enter on the Company Sign In screen on the
mobile device (described on the following pages).

NOTE: The Company Code cannot be customized by the client; it is auto-generated

by Concur.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Email

Users will see the email shown below:

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
What the User Sees on Mobile

Where there are standard users or Mobile SSO is not enforced.

iPhone

Android

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Mobile SSO Enforced

iPhone

Android

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
**Optional** Mobile SSO Enforced or not Enforced

iPhone

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Android

SSO on the BlackBerry

Whether or not SSO is configured, the regular log in screen appears. If a user
chooses (or is instructed by their company) to use SSO, the user taps Having
Trouble Signing In?

The user enters the company code obtained from the Mobile Registration page in
the web version of Concur. The user taps Submit.

The user is then directed to the corporate login page for mobile. The user enters
his/her corporate user name and corporate password, then selects Login.

From now on, the user sees the corporate login page when logging in to the mobile
app.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Use Cases

Install

User downloads the Concur app:

 App Store
 Google Play
 BlackBerry App World
 OTA site
 BES Push
 Other

Initial Login

1. User launches the Concur app on the smartphone.

2. Next:

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
  Blackberry: User taps the Having trouble signing in? link and enters
their Mobile SSO Company Code.
 iOS/Android: User taps Sign In, then enters their Concur login or email
address then is directed to their company site. (if SSO is required)
- Or -
User selects SSO Company Code Sign In then enters their company’s
code

3. Concur reads the connection data (IDP URL).

4. Concur opens the embedded web view.

5. User is auto-directed to the Company-supported mobile login UI.

6. The URL will not be visible to the user.

7. User enters the corporate login credentials.

8. Company validates the credentials.

9. Company sends this to Concur Travel & Expense thru SAML.

10. Temporary session ID is created.

11. Temporary session is exchanged for a standard.

12. Concur establishes a valid session cookie.

13. Concur establishes a valid mobile session.

14. Company URL is stored encrypted to device/key chain.

15. User is taken to the mobile home screen.

Subsequent Login

1. User is actively using Concur.

2. User closes Concur.

3. User launches the Concur app on the smartphone.

4. Concur attempts to validate the session.

5. Concur detects a valid session (the inactivity timeout has not occurred).

6. User is taken to the home screen.

Company Session Expires

1. User is actively using Concur.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 2. User closes Concur.

3. User launches the Concur app on the smartphone (remember, this device is
using SSO to connect).

4. Concur reads company URL from the device cache (the encrypted URL is
refreshed from the server).

5. Concur attempts to validate the session.

6. Concur sends an invalid session message.

7. Concur opens the embedded web view.

8. User is auto-directed to the Company-supported mobile login UI.

9. User enters the corporate login credentials.

10. Company validates the credentials.

11. Company sends this to Concur Travel & Expense thru SAML.

12. Temporary session ID is created.

13. Temporary session is exchanged for a standard.

14. Concur establishes a valid session cookie.

15. Concur establishes a valid mobile session.

16. User is taken to the mobile home screen.

Logout

This should be used if user is actively using Concur and switching between different
company accounts (for example, if they are a contractor).

1. Depending on the phone manufacturer:

iPhone:
 User selects the Settings menu.
 User selects the Logout button.
 User is taken to the login screen.

BlackBerry:
 User selects the BlackBerry menu.
 User selects the Logout option
 User is returned to the login screen.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
 Android:
 User selects the Android menu.
 User selects the Logout option.
 User is returned to the login screen.

2. Concur clears the company URL from the device cache.

3. User launches the Concur app on the smartphone.

4. User goes to the Initial Login flow.

Clear Cache

Where the user is actively using Concur.

1. Depending on the phone manufacturer:

iPhone:
 User selects the Settings menu.
 User selects the Clear out the local cache option.
 User confirms deletions.
 User selects OK.

BlackBerry:
 User selects the BlackBerry menu.


 User selects Options.



 User selects the Erase Saved Data option.

Android:
 User selects the Android menu.
 User selects the Clear offline data option.

2. Concur clears the company URL from the device cache.

3. Concur clears the IDP from the device cache.

4. User closes Concur.

5. User launches the Concur app on the smartphone.

6. User goes to the Initial Login flow.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Remote Wipe

Where the user is actively using Concur.

1. User closes Concur.

2. Company admin access the User Admin in Concur Travel & Expense.

3. Company admin searches for the user.

4. Company admin access the user record.

5. Company admin checks the Remote wipe mobile device box under Mobile
Settings.

6. Concur sets the remote data wipe flag.

7. User launches the Concur app on the smartphone.

8. Concur detects a token IDP.

9. Concur reads company URL from the device cache.

10. Concur will send the cookie to the company URL.

11. Company attempts to validate the token.

12. Company returns a valid message.

13. Concur attempts to establish a web session.

14. Concur detects the remote data wipe flag.

15. Concur clears the company URL from the device cache.

16. Concur clears the IDP cookie from the device cache.

17. User goes to the Initial Login flow.

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Flow Charts

Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017
Concur Technologies
Copyright © 2017 Concur Technologies. All rights reserved. Last Revised: April 12 2017