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?
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.
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.
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:
Users will need to know at least one of those three options to move forward with the authentication.
Based on what we just learned, here are the steps a non-SSO user would follow through this SP-Initiated process:
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. |
In contrast, here are the steps followed by a user using unenforced SSO through this SP-Initiated process:
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.).
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.
To best understand this process here are the steps followed by a user using unenforced SSO through IdP-Initiated process:
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.
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.
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:
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).
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:
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.
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:
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!
Native Authentication:
SSO:
At SAP Concur you have three main SSO enforcement options:
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
2 | |
1 | |
1 | |
1 | |
1 |