Technical Articles
Identity Authentication Service(IAS) Configuration approach with SAP SuccessFactors Application
Introduction
In Future, all SAP Success Factors applications will be integrated with Identity authentication service(IAS). and you can leverage IAS functionalities and configure it as per your requirement.
Pre-requisites:
Users are properly synced from SAP SuccessFactors(SF) Application to IAS. If you are wondering why user sync is required, kindly read the blog:
Why Identity authentication is required for SAP SuccessFactors Application
Approaches
Depends on the requirement and the required end user experience (after the configuration)
You can follow 2 approaches:
Approach A
- Use Corporate IDP as default Identity Provider in SAP SF application
- For only 1 Corporate Identity Provider(IDP) for SAP SF application.
- Seamless single sign on experience to users(Corporate Employees)
- After the configuration of IAS is completed with SAP SF application, when user access the SAP SF URL – it will directly take you to corporate IDP without stopping anywhere and in case you are already logged into Corporate IDP, you will logged into SAP SF application without stopping anywhere.
- For all Password Users – there will be another URL and all Password users will be authenticated in IAS.
Benefits:
Seamless Single Sign on experience
Drawback:
Maintain 2 different URLs for different Users(corporate employees and external vendors)
This approach is very similar to how it was earlier without IAS. There is one advantage though.
- Because we have synced the users from SAP SF application to IAS – you can enable mapping in IAS using option in corporate IDP( user IAS USER STORE) so that you can have different identifiers at Application and IDP
- Please read the blog mentioned in Pre-requisite in case you don’t what I am taking about.
Approach B
- Use Rule based conditional authentication
- Have multiple Corporate Identity Providers as per different regions and planning to add more in future for SAP SF application
- Want 1 single URL for all type of users( SSO and Password Users) – Corporate employees and External Vendors.
Benefits:
- More Flexibility, can add more Corporate IDPs in future
- less management as there will be only 1 URL for all types of users
Not a drawback but default behavior:
- After Configuration is completed, when you access SAP SF URL – it will bring you to IAS Screen- where you enter your email address(or LoginName – Username in SAP SF) and it will now redirect you to Corporate IDP (in case of corporate employees) or you will authenticate in IAS (in case of external vendors)
- In case of corporate employees – for first time it will stop at IAS screen, however for next it will not stop on IAS screen( until you clear your browser cookies)
In this blog post, you have learnt about different approaches we can follow while doing integration of IAS with SAP SF application.
See you in next blog !
Hi Sushil Gupta
Thank you for you blog, I have read all your 5 IAS realted blog, really appreicate it!
We have Azure as corporate IDP, this scenario have been mentioned only this one but also your other blog, I still have some questions, Please allow me to confirm if my understanding is correct about the approach and what should be considered.
The background: a) Successfactors have all user but Some user only exists in Successfactors b)Client want to restrict IP range for people who is not existed in Corporate IDP.
Could you confirm if my understanding is correct about these points below?
1)We need attributes to target which employee is existed in corporate IDP if we want to use risk based authentication to restrict IP range?
2)Should we maintain password policies in IAS instead of corporate IDP?
I understand form your other blog that we need IAS user store and we can use conditional authentication to maintain only one URL. I think we need enable user store to use risk based authentication to restrict IP range
3)Who is the target of the IAS password policies? all the users in IAS (include the user in Corporate IDP and user only existed in IAS) or the user only exists in IAS?
Look forward to hear from you!
bojun
Hi Bojun Zhao,
Please find my reply below:
1)We need attributes to target which employee is existed in corporate IDP if we want to use risk based authentication to restrict IP range?
I didn't understand it. Kindly re-brief the question. What is target here we are mentioning? To use Risk based authentication - you will need users to be synced from SAP SuccessFactors to IAS (using IPS ) - which is a part of standard steps - of IAS integration with SAP SF application.
Attributes (If we are talking about SAML attributes) - you can configure the attributes as per the requirement. Identifier is something which will be critical( NAMEID - if you use SAML tracer to capture the trace - you should see it with this name)
You can put the users in a separate group and provide that group in Risk based authentication - as per your requirement (You can use User Type or IP ranges also) - this is to allow, completely disable the access or enable 2 factor authentication to set of users.
2)Should we maintain password policies in IAS instead of corporate IDP?
It depends on where you want users to get authenticated - in case Users are getting authenticated in Azure AD(like you mentioned initially) - password policy of Azure AD follows.
In case you want some set of users to get authenticated in IAS(like some external vendors) then you can define password policy in IAS.
3)Who is the target of the IAS password policies? all the users in IAS (include the user in Corporate IDP and user only existed in IAS) or the user only exists in IAS?
All the users which will use IAS as identity provider and will authenticate in IAS - will be target of IAS password policy.
Any user which is getting authenticated in other Identity providers will not use this password policy of IAS.
We should not confuse it with all the users in IAS( as they have some other purpose also) - like in case of different identifiers - we need the users details in IAS to do the mapping - however at the end authentication is happening in some other corporate IDP (like azure AD) - so password policy of Azure AD follows.
Just want to share the below info:
Conditional authentication: Its going to manage where your users will get authenticated - in IAS or in Azure AD or some other corporate IDP.
Risk based authentication:
You can create rules - here to allow , disable the access or enable 2 factor authentication to different set of users( you can segregate using IP ranges, Usertype or user groups)
Hope this helps ! let me know if you have any other questions .
Happy to help !
Regards
Sushil K Gupta
Hi Sushil Gupta
Thank you very much!!
This really helps a lot! Good for me can find your blog.
about the first question, I am sorry about the confusion.
in our case, some employee only exists in Successfactor not in Azure. based on your previous blog, I am thinking to use user group as condition so we can only maitain one url for corporate IDP employee and IAS employee.
Plus we also want to restrict the IP range for the employee who is not existed in Azure.
So My understanding is that we need some attribute to know which employee dont exist in Azure.
the problems we are facing is that we don't have any attribute to recognize these two kinds employee.
Is there any possiblity that IAS can recognize which employee exists in Azure instead of maintaining additional attirbute in Successfactors?
Hi Bojun,
Please find my reply below:
Is there any possiblity that IAS can recognize which employee exists in Azure instead of maintaining additional attirbute in Successfactors?
Yes , its possible.
You can filter the users as per the domain names ( for example your Azure AD users have lets say 10 domain names)
If you select - 1st approach from this blog - in that case all users by default will go to azure AD - whatever users which don't exist in Azure AD won't be any how not be able to login (because there is no user on IDP side)
Kindly follow the admin guide from SAP - this will help you with the process
https://help.sap.com/viewer/568fdf1f14f14fd089a3cd15194d19cc/2011/en-US/fb069584363a4df08aad42315cebdd6d.html
Regards
Sushil K Gupta