Some background to SSO
Single Sign On has been around for years. The variant that most of us use with web-based tools is known as Security Assertion Markup Language (SAML) (often pronounced SAM-el or SAM-al). Specifically, the version 2.0 which has been an OASIS (Organization for the Advancement of Structured Information Standards) standard since 2005. There are other versions of SSO that you will probably have come across, but in the general market today there is an overwhelming support for SAML2.0. There is some movement toward using JSON Web Tokens (JWT) to manage SSO rather than SAML but for this discussion let’s just stick with the areas that are well defined!
SSO (both SAML or JWT based) depends on two different servers – the application (e.g. SAP SuccessFactors) and the identity provider (e.g. Microsoft Azure AD). The application (also known as the service provider or SP) and the identity provider (IdP) share some secrets with each other in the form of public key cryptography*. Each system knows the public key of the other system and uses this along with its own private key to sign messages. Thus, the two servers know when they are sharing messages securely.
There are two ways to initiate SSO – SP initiated (probably most common) and IdP initiated**. As the names suggest these are different in that SP initiated starts with the user accessing the application which then starts the authentication flow. In IdP initiated flows the user starts with a link to the IdP which then will forward the user to the application. What’s important for this discussion is that if the application uses deep links in, for example, emails sent from the system – e.g. a link to complete your performance review that will take you directly to the performance review document – then these will pretty much always trigger SP initiated SSO – because the link is to the application URL, not the IdP.
So how do we set this up when we need to have both SSO and Password users?
With the background out of the way – let’s discuss the particular situation which I’ve found a fair bit recently.
When implementing SAP IAS (Identity Authentication Service) for a few SAP SuccessFactors customer recently, they have needed the ability to be able to log into the system either via SSO (majority of users) or via password (small number of users). Mainly this has been triggered because not all of the users of the solution are in the main corporate IdP. With IAS, the possibility to enable multi factor authentication within the SAP tooling means that paying for an IdP subscription for these people isn’t necessarily worthwhile anymore from a security standpoint, so more customers taking this opportunity to not put all employees in the IdP.
IAS has two methods for enabling this possibility. Both are configured in the conditional authentication area of the application configuration in IAS.
Option A
In the first set-up, you configure IAS to pass all authentication requests to the IdP. To make things easier to follow let’s call this “Option A”. This means that if a user is logged into the IdP they get “true” SSO – no need to enter anything and they are logged into SAP SuccessFactors (as long as they are already logged into the corporate IdP – which for AS. For those users that are not in the IdP there is the possibility to enable an additional “Allow Identity Authentication Users Log On” setting which gives a URL that users can then use to use password login to IAS.
Option B
In the second setting, let’s call it “Option B”, we enable rules in the conditional authentication that directs those users that are part of an SSO group to the corporate IdP for SSO and those users that are part of the password group (i.e. not in SSO group) to use IAS.
Generally, I would define a Password group so that I can set risk-based authentication rules to force all password users to require the use of Multi-Factor Authentication (MFA).
I set up the different groups in IAS based on the existing login method field in SAP SuccessFactors, it’s fairly easy to do***, you can still find some of the details on the SuccessFactors IAS/IPS setup help site about the IPS transformations that may be needed.
Differences in User Experience
In Option A if you do have users that are not in the corporate IdP then deep links will only work for them if they log into SuccessFactors/IAS first via the special link.
In the second setup, Option B, all users must enter their email address/username before they are redirected to SSO via corporate IdP or password login.
To mitigate the second setup not having “one-click” access to SAP SuccessFactors for already signed-in users, it is possible to use IdP initiated SSO as the “link” to use for most users to log into SAPSF.
The entry of email address/username cannot be totally avoided however as, users would still need to do the “enter email address” step if they followed a link sent in an email – as this would do SP initiated login, redirect to IAS not corporate IdP.
This said, IAS does retain the last username/email that you logged on with and save this as a persistent cookie with 90-day lifetime and pre-populate the login details… so other than the first time a user logs in, it’s likely that with Option B users will only need to click/press one extra button to redirect to corporate IdP (and then log in there, if not already) for SSO in to SuccessFactors.
It is worth considering not even using the corporate IdP initiated login for option B just to ensure that the login experience is consistent between following a link in an email and the “portal” or “homepage” link experience. It will depend on how much value is put on ease of login vs. consistency.
| Configuration option | User Type | Experience – link from main company portal page | Experience – link from deep link (to specific area of SAP SuccessFactors) | How Good? |
| Option A default Corporate IdP login | SSO | One click and in (if you’re already logged into corporate IdP) | One click and in (if you’re already logged into corporate IdP) | |
| Option A default Corporate IdP login | Password | Need to have “special” link for these people can’t use same link | Issue as user not in IdP, need to remember to follow special link first to log into SuccessFactors, then click deep link | |
| Option Bdefault IAS login | SSO | Either set up different IdP initiated login link for these people, then one click and in (if logged into Corp IdP), or user prompted to enter email address (which may be defaulted if they entered it in last 90 days and haven’t cleared their cookies) | User prompted to enter email address (which may be defaulted if they entered it in last 90 days and haven’t cleared their cookies) then in (if already logged on to corporate IdP) | |
| Option Bdefault IAS login | Password | user prompted to enter email address (which may be defaulted if they entered it in last 90 days and haven’t cleared their cookies) then prompted to enter password. | user prompted to enter email address (which may be defaulted if they entered it in last 90 days and haven’t cleared their cookies) then prompted to enter password. |
What do SAP recommend.
Well, until I gave this doc to my good friends at SAP (Vish G, Paul T and Marko S) to review to see if I’d made some errors, I had to go by the details in the SAP help documentation:
where it says you have two options.
“Option A: Define the Corporate Identity Provider as Default Authentication IDP for the SAP SuccessFactors Application”
But for some reason, in a most Monty Pythonesque way – there is no Option B.
By the time you read this there may well be an option B in the documentation.
There also is one note/KBA 2954556 “How to implement Partial SSO after IAS implementation on SuccessFactors” where SAP are recommending using Corporate IdP and alternative link approach. Strangely enough, just like the current help doco they don’t even mention that there are other possibilities in that KBA. (Again, with a little bit of a luck, hint, or push, it may well be that this also changes by the time you check out that KBA).
Either way, at the moment, it’s not really a recommendation, more an explanation of different possibilities. Recommendations, it seems are left for opinionated people like me to deliver!
So, what do I recommend?
If you only have a handful of non-SSO users, potentially consultants supporting your system or other people who understand that they are “special” and need to behave in a special way to use the system, then use the corporate IdP as the default identity provider (Option A). Otherwise, use the IAS with conditional authentication (Option B). I’d recommend that you don’t use an IdP initiated login link, as it won’t work for password users and will likely cause confusion when deep links behave differently. I’d only suggest using the IdP initiated login link if there is an expectation from the senior executive sponsors of the solution that it should be “one click and in” and they don’t seem receptive to the various details I’ve mentioned – they just hear “Techno babble, blah, blah blah, excuse why you can’t make it do what I was told by the sales people that it could do… blah blah blah.” I’ve seen some of those situations, logic can’t help you, just give them the IdP initiated login link.
That’s all folks
Hopefully, that was useful! It seems this was a slightly shorter post that I was fearing it was going to be before I started writing! If there’s anything you’d like to follow up on or ask – please do post a question in the SuccessFactors community, there are no doubt many people who have been through the fun of IAS implementations who can offer advice, including myself.
If you looking for more info – start at the SuccessFactors community post about IAS – https://community.successfactors.com/t5/Platform-Resources-Blog/Migration-to-SAP-Cloud-Identity-Authentication-With-IAS-IPS-from/bc-p/272831 and check out all the links there. Read all the comments and questions that others have asked, and others have answered.
Then if you have more questions, please come to one of the weekly Office Hours, where you can ask questions and hopefully have them answered. The team from SAP are super knowledgeable and super friendly and are just waiting to help you be successful. (And I might be there too being opinionated if you join the APJ time-zone friendly session!)
This article was originally published on the SAP SuccessFactors community website.
*Explaining how public key cryptography works is way beyond the scope of this post, and there are hundreds of people who’ve done great work doing this. If you don’t understand public key cryptography, do yourself a favour and go and research it. It is the tooling which underpins most of the internet. It’s not that hard a concept! I wrote a simple RSA encryption algorithm for a game my friends and I were playing where we had to pass a floppy disk between us to take turns back when I was 13 so that we could send each other messages secure in knowledge that the others couldn’t read the messages. Given that I wrote the code in GW-BASIC which only handled 16bit integers, I’m pretty sure one of my friends could have brute-forced the codes… but this is pointless reminiscing, the point is, just go and learn how it works!
**There is a case that can be made that IdP initiated SSO is less secure than SP initiated SSO because it can more easily be used in man-in-the-middle attacks. However, given that all applications and IdPs would be using HTTPS (TLS) to encrypt their communications, if a MITM attack can intercept the authentication assertion, you’ve got bigger problems than your SSO being compromised.
*** Okay, it’s easy for me because I’ve done it lots of times! If this is the first time that you’re trying this, yes it isn’t easy. Sorry! I’m not going to go into the details of what you need to modify in your IPS setup to enable the split between password and SSO groups and even sending different email notifications (or not) to the two different groups, that’s probably a decent sized post just by itself. Stay tuned though as I’m planning to put something together for my next presentation at SAP Australia User Group Summit on this.
