Spend Management Blogs by SAP
Stay current on SAP Ariba for direct and indirect spend, SAP Fieldglass for workforce management, and SAP Concur for travel and expense with blog posts by SAP.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

How can Single Sign-On be enforced at SAP Concur?

erick_f_reyes
Associate
Associate
Friday
0 Kudos
248

LeftHeader.png

To skip to the answer,
scroll to the bottom to TL;DR section!

Last updated November 1, 2024 

During a recent SAP Concur site implementation my customer was presented with a conundrum: their security guidelines directed them to enforce Single Sign-On (SSO) whenever possible. This was not a problem for their full-time employees, as they were part of their active directory. However, they also planned to bring over contractors that worked on various locations scattered around the country, and those users were not part of the active directory structure. Then, they wondered, how could they enforce SSO at SAP Concur?

SSO Enforcement: Because not everyone has a facial recognition system.SSO Enforcement: Because not everyone has a facial recognition system.

As an SAP Concur consultant this has been a common situation for many of my customers, particularly in industries that include different levels of employment and security policies. It is not uncommon for customers to have third-party vendors that rely on non-SSO access to SAP Concur to render their services, or where their security policies allow for flexibility in authentication methods. In contrast, there are other companies that have very strict security guidelines that require a complete enforcement solution. The challenge, as it stands, is to be able to deliver solutions that accommodate the different levels of security and capabilities required.

As SSO enforcement is one of the key industry standards, in this blog we will explore how authentication works at Concur, present to you the different challenges you may face, and share with you the current available options on how to fulfill this security requirement.

disclaimer.png


Log In starting at SAP Concur (SP-Initiated)

To begin I’d like to focus on the SAP Concur login page and Mobile app, as both present a Login page available to all our customers. This is an authentication where the user is starting the process at the Service Provider, in this case, SAP Concur. This is commonly known as Service Provider Initiated authentication, or SP-Initiated for short.

One page to rule them all, one page to find them, one page to log them in and in SAP Concur bind them.One page to rule them all, one page to find them, one page to log them in and in SAP Concur bind them.

 

For a user to be identified as belonging to a specific instance by SAP Concur, the system requests that they identify themselves via their Login ID (username), verified email address, or SSO code:

  • The user’s Login ID (username or CTE Login Name) is a key identifier defined at user creation, and it is a value that must be unique in the entire SAP Concur system.
  • Each user can verify an email address by logging in to SAP Concur and completing the verification process under Profile > Personal Information > Email Addresses. Once completed the related email address is uniquely associated to that profile. Users can only verify their email once in the entire SAP Concur system, i.e. users cannot verify the same email address on multiple SAP Concur profiles.
  • SAP Concur can create an SSO code if requested. This is a unique, company-wide code for your SAP Concur instance. It must be 3-10 alphanumeric characters in length and not contain the characters 0, 1, F, I, O, or S.

Users will need to know at least one of those three options to move forward with the authentication.


SP-Initiated: Non-SSO Authentication

Based on what we just learned, here are the steps a non-SSO user would follow through this SP-Initiated process:

  1. User visits the SAP Concur Login page (or Mobile app).
  2. User enters their SAP Concur Login ID (username), verified email address, or SSO code.
  3. Once a valid value is provided the next screen asks the user to select one of two options:
    1. The first button allows the user to log in via Password as defined by the instance's Sign In password policy. Once a valid password is entered the following screen asks the user to complete the two-factor authentication process.
    2. The second button allows the user to Sign In with an Email.
  4. User is authenticated.

Since the process to log in to the Mobile app is the same, we understand this as a unified user flow, i.e. all users have the same login experience on either browser or mobile, making it ideal in terms of simplicity and behavior.

NOTE: A quick reminder that the Mobile app does allow saving locally the initial identifier provided in step #2, and therefore the steps above will only apply in full if the user is in an initial state (e.g. the user signed out of the app, deleted local cache, etc.).

USING AN OLD SSO SOLUTION AT SAP CONCUR?

Please note the following sections describe the flows under the latest SSO solution offered at SAP Concur. If you intend to enforce SSO for any of our older solutions please scroll down to Legacy enforcement.


SP-Initiated: Unenforced SSO Authentication

In contrast, here are the steps followed by a user using unenforced SSO through this SP-Initiated process:

  1. User visits the SAP Concur Login page (or Mobile app).
  2. User enters their SAP Concur Login ID (username), verified email address, or SSO code.
  3. Once a valid value is provided the next screen asks the user to select one of three options:
    1. At the top the user will see their SSO option(s) as individual button(s). Once they click a button then the SSO process is triggered. If the user has already internally authenticated, then this step is invisible to them. Otherwise, this step may show a screen to allow the user to authenticate internally.
    2. The next  button allows the user to log in via Password as defined by the instance's Sign In password policy. Once a valid password is entered the following screen asks the user to complete the two-factor authentication process.
    3. The last button allows the user to Sign In with an Email.
  4. User is authenticated.

As we can see the flow is virtually the same as the previous one, with the only difference being the additional button(s) for each SSO configured. This is the same across both desktop and mobile, meaning we maintain the unified user flow.

NOTE: As mentioned earlier, please note the Mobile app does allow saving locally the initial identifier provided in step #2, and therefore the entire flow will only apply in full if the user is in an initial state (e.g. the user signed out of the app, deleted local cache, etc.).


Log In starting at your SSO side (IdP-Initiated)

The alternative to the users starting the process from SAP Concur is, instead, for them to log in through a URL or portal provided by your company and/or your SSO provider. As this process has the user start from your side, the Identify Provider, this is referred to as Identity Provider Initiated authentication, or IdP-Initiated authentication. This process can be done for authentication through a browser, but it isn’t an option for the SAP Concur Mobile app, as that process is SP-Initiated only.


IdP-Initiated: Unenforced SSO Authentication

To best understand this process here are the steps followed by a user using unenforced SSO through IdP-Initiated process:

  1. The user clicks on a URL or visits an internal portal where they would click on the Concur link or button.
  2. The SSO process is triggered. If the user has already internally authenticated, then this step is invisible to them. Otherwise, this step may show a screen to allow the user to authenticate internally.
  3. User is authenticated.

As we can see the flow is distinctly shorter than the SP-Initiated authentication flow, as it provides a more direct process into SAP Concur. However, it is important to highlight once more how we lose the unified user flow as the SAP Concur Mobile app must continue to follow the SP-Initiated Authentication flow.


How can we enforce SSO at SAP Concur?

Full enforcement

This option is only available for customers using our latest SSO solution, and it is an all-or-nothing approach, as all users must have access to the site via SSO.

To implement this solution you simply need your SSO Administrator to log in to SAP Concur, go to Administration > Company Admin > Authentication Admin > Manage Single Sign-On, and under Enable SSO click on the dropdown for SSO Setting.

erick_f_reyes_0-1730331156038.png

As you may notice in the FAQ of the Single Sign-On Setup Guide and on the screen (as you attempt to change this setting) it is critical that this change is done with care, as it will remove the Password option completely for all users, including vendors. It is best practice to start your SSO implementation with SSO listed as SSO Optional until you have defined a clear change management and validation process to support this modification.

This option covers all three main challenges we identified earlier, as all users would be using SSO and no other option would be available. 

To clarify, here are the steps followed by a user using Fully enforced SSO through this SP-Initiated process:

  1. User visits the SAP Concur Login page (or Mobile app).
  2. User enters their SAP Concur Login ID (username), verified email address, or SSO code.
  3. The next step depends on the number of SSO connections available:
    1. IF the SAP Concur site has multiple SSO connections then the next screen shows to the user the different SSO button(s) available. The user needs to click an option.
    2. ELSE If the SAP Concur site has a single SSO connection then no further Concur screens are shown, and we move to the next step.
  4. The selected SSO process is triggered. If the user has already internally authenticated, then this step is invisible to them. Otherwise, this step may show a screen to allow the user to authenticate internally.
  5. User is authenticated.

The IdP-Initiated process is the same as described earlier (no change).

As we can see, this is an option that is very easy to set up, but one that has no flexibility. It requires you to ensure all users will have access to SSO for all time (or at least until you change this setting back to SSO Optional).


Legacy enforcement

Many customers have employees, contractors, and/or vendors outside of their SSO solution and need a more flexible solution. This is where SAP Concur’s Legacy enforcement may be a valid alternative. This is also the only option for any customer under our older SSO solutions.

To implement this type of enforcement multiple steps would need to be planned, approved, and completed by both you and SAP Concur:

  1. Identify authentication for valid non-SSO users: Defining a policy for non-SSO users, as moving forward they will only be able to log in via Password/Two-factor authentication, and only administrators will be able to assign valid passwords to those non-SSO users.
  2. Change management: Planning, communication and support of this change would need to be discussed and defined. It will be critical to define a day to implement the change.
  3. On your chosen date apply the changes needed:
    1. Disable Sign In via Email: Sign in via Email must be disabled by your Authentication administrator to avoid having SSO users leverage that feature.
    2. Block all password reset options: Setting changes are applied by SAP Concur to hide all options for your users to request a password reset to the system. Only administrators would be allowed to change passwords.
    3. Scramble all existing passwords: Setting changes are applied by SAP Concur to scramble all user passwords en masse. This would need to come right after the previous step to avoid users attempting to reset the scrambled password.

While a good workaround, the biggest caveat with this solution is that any SP-Initiated process (mobile and desktop) would match the Unenforced SSO Authentication flow shared earlier in this blog (minus the Sign in via Email option), meaning SSO users would be able to see the password option, but not be able to use it. This can’t be avoided due to the nature of the Concur login page as a unified, global page.

Please plan on submitting your Legacy SSO enforcement request to SAP Concur ahead of time (steps 3b and 3c). This will allow careful planning and execution of your request.


Final thoughts

During many of the conversations I’ve had with my customers there has been an initial bias towards finding the easiest, fastest solution that would solve their SSO enforcement. That is, of course, not an approach that can be applied to every situation. Throughout the years I’ve had customers where SSO enforcement is an easy choice (and in cases defined processes to move non-SSO users to active directory for full SSO), others where the security options available for non-SSO were sufficient and enforcement was not needed, and some that decided to set up Legacy enforcement to comply with business needs and requirements. These are decisions that warrant full conversations between different key owners to find the best possible solution that matches your user and security needs.

Please consider the following:

  • Familiarize yourself with all the Sign In options available, their user flows (and its ease of use), and the level of security you can apply to each.
  • The SSO solution available at SAP Concur is global by design and we do not currently allow for configuration by group. This makes it critical to identify if any portion of your userbase would need non-SSO access, and whether it needs to stay that way (thus preventing full enforcement).
  • The SAP Concur login page and Mobile app are public facing landing spots that can’t be blocked or restricted. This means that any authentication option must account for access through these flows.
  • Authentication needs to take into consideration requirements and limitations – whether users need to be able to log in while traveling, require tokens, device management, etc.
  • Based on all the gathered information, explore SSO enforcement options at Concur that works best for you. Not one size fits all!

I hope that this blog post helps you start the conversation to find the required strategies to best fulfill your particular security and requirements.

Until next time!


References

Native Authentication:

SSO:

 

 

TL;DR – How to enforce SSO at SAP Concur

At SAP Concur you have three main SSO enforcement options:

  1. No Enforcement: Users can log in via SSO OR with a valid Concur password (with Two-Factor authentication) OR Sign In via Email Link (new option as of August 2024).
  2. Full Enforcement (only available under our latest SSO solution): You enable this by changing the SSO Setting from SSO Optional to SSO Required in the Manage Single Sign-On page. This effectively removes any non-SSO option completely from the solution and affects ALL users (no group-aware enforcement currently available).
    This can be implemented directly by you, the customer. For more information please review our FAQ of the Single Sign-On Setup Guide.
  3. Legacy Enforcement: With this option your SSO is not officially enforced. Instead, steps are taken to only allow certain users to have valid passwords.
    Steps needed:
    1. Define the policy to follow for SSO and non-SSO users.
    2. Plan for this change (target date, communication and support steps defined).
    3. On the targeted date:
      1. Administrator(s) remove Sign In via Email option and assign valid passwords to valid non-SSO users.
      2. Block all password reset options for end users (only User Administrators having access).
      3. Scramble all existing passwords.

To implement this option please reach out to SAP Concur ahead of time as steps Cii and Ciii can only be done by SAP Concur resources. In this scenario only targeted users would have a valid password at the end of the process and moving forward any password reset/creation would be only available through User Administrators. Two-Factor authentication would still be a requirement for non-SSO users (as this requires you to disable the Sign In via Email option).

Please remember to explore these options and validate against your security policies to ensure you have the best possible solution that matches your needs!

Popular Blog Posts