Skip to Content
Technical Articles
Author's profile photo Harjeet Judge

Provision users from Microsoft Azure AD to SAP Cloud Identity Services – Identity Authentication

In this blog I will use SAP Cloud Identity Services – Identity Provisioning to replicate users from Microsoft Azure Active Directory to SAP Cloud Identity Services – Identity Authentication.  Before we get into the detailed steps, let’s quickly review the purpose of each one of these components.

SAP Cloud Identity Services – Identity Authentication (IAS) is SAP’s cloud based SAML2 Identity Provider.  IAS provides you with controlled cloud-based access to business processes, applications, and data. It simplifies your user experience through authentication mechanisms, single sign-on, on-premise integration, and convenient self-service options.

SAP Cloud Identity Services – Identity Provisioning (IPS) allows you to manage identity lifecycle processes for cloud and on-premise systems.  IPS automates identity lifecycle processes. It helps you provision identities and their authorizations to various cloud and on-premise business applications.

Microsoft Azure Active Directory – Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service and serves similar purpose as SAP Cloud Identity Services – IAS

The following picture highlights the scenario that we will setup with IPS.  In our case, the source system will be Azure AD and target system will be IAS.

Before we get into the process of replicating users from Azure to IAS, let’s briefly look at the setup of my Azure AD users and groups.  I have 10 users(ipsUser_01 to ipsUser_10) in Azure AD and they members of one of 2 groups: SAPCloudUsers1 or SAPCloudUsers2.

The screenshots below show couple examples of the user profile setup in Azure:

I’ve highlighted certain fields from the user profile because we will need to make changes to the default IPS rules to ensure fields like EmployeeID, Department, City and Country are handled.  Some additional aspects to note for the users:

  • The Country value for the users is set to Canada.  IAS user profile expects country code instead of country name.
  • Mobile phone number is empty for some users.  IPS rules will have to be adjusted accordingly to handle this scenario.

In order to replicate users from Azure AD to IAS we will need to perform the following steps:

  1. Register an application with Microsoft Graph API
  2. Setup Azure AD as a source system in IPS
  3. Setup IAS as a target system in IPS
  4. Run the source provisioning job

I’ve also added a supplementary section at the end that covers how the properties and transformation rules can be modified in source and target system to handle specific scenarios.

Register an application with Microsoft Graph API

  1. Launch a browser window and access your Azure portal using the URL:  You will need to authenticate to your Azure AD using your admin credentials.
  2. Click Azure Active Directory.
  3. Click App Registration >> New registration.
  4. Specify a name for your app and click Register.
  5. Click API permission >> Add a permission.
  6. Select Microsoft Graph.
  7. Click Application permissions.
  8. From the list of API permissions, expand User and select User.ReadWrite.All.
  9. From the API list also select Group >> ReadWrite.All and Directory >> ReadWrite.All.  Click Add permissions at the bottom of the screen once done.
  10. The permissions are not granted by default.  To grant the permissions, click Grant admin consent for Default Directory.
  11. Click Yes on the popup message and confirm that all permissions are granted.
  12. Click Overview from the left panel.  Make a note of the Application (client) ID.  You will need this later when creating the source system in IPS.   Click Add a certificate or secret.
  13. Click New client secret.
  14. Specify a description and expiry time for the client secret.
  15. You should have client secret added successfully.  Make a note of the value field as you will need it later when creating the source system in IPS.
  16. Navigate to the main overview page of Azure AD and make a note of your Primary domain.  You will need this value when creating the source system in IPS.

This completes part 1 of the setup.

Setup Azure AD as a source system in IPS

  1. Access your SAP Cloud Identity Services – Identity Provisioning (IPS) tenant.
  2. Click on Source Systems.
  3. Click Add.
  4. Specify the following and click Save:
    • Type: Microsoft Azure Active Directory
    • System Name: <name of your choice>
  5. Click Properties. You will see a list of pre-created properties.
  6. Click Add to add new properties.  Use the Standard option for non-sensitive properties and Credential option for password fields.
  7. Add the following properties one by one and click Save.  The list below is minimum set of properties that are required for IPS to read user/group information from Azure.  These properties can be further customized, for eg. to filter for specific users and/or groups.  Take a look at the help guide for the complete list of properties that are possible with Azure AD as a source system.
    • Type: HTTP
    • ProxyType: Internet
    • URL:
    • Authentication: BasicAuthentication
    • User: <Application (client) ID> – See step 12 above.
    • Password: <Shared secret value> – See step 15 above.
    • <your Azure AD domain> – See step 16 above.
    • OAuth2TokenServiceURL:<>/oauth2/token  – Change the <> to match your Azure AD domain.
  8. Now before we wrap up the configuration of the source system, it’s also important to check the transformation rules.  There is a slight issue with default transformations that if not corrected may cause the IPS read jobs to fail for certain users.  Click on Transformations and click Edit to modify the default transformations.  Scroll down until you find the condition highlighted in red and change it as per the screenshot highlighted in green.  The modified rules will handle the scenario where the user profile in Azure AD may not have mobile phone value populated.  The rules simply add a default value for the mobile phone in such a scenario.  Without this change, any user that only has the Office phone field populated in Azure will fail during the provisioning job.
  9. Optionally set the parameter that ignores Azure AD groups.  The default is set to true so the provisioning job will not read Azure AD groups.  I set this to false so that I can read both users and their group membership from Azure AD.
  10. Save your changes.

This completes part 2 of the setup.

Setup IAS as a target system in IPS

Before we can setup SAP Cloud Identity Services – Identity Authentication (IAS) as  a target system in IPS, we need to create a system users in IAS with the proper privileges to provision users.

  1. Open another browser tab and access your IAS Administration console.
  2. Under Administrators, click Add >> System.
  3. Specify a name for your user and ensure the following authorizations are enabled:
    • Manage Users
    • Manage Groups
    • Manage Tenant Configuration
  4. For Set Password section, click Not Configured.
  5. Specify a password for your user and click Save.  After saving, you will redirected back to the previous screen.  Navigate back to the password screen and copy the User ID using the Copy icon.  We need this User ID and the password later when setting up IAS as a target system in IPS.
    We now have everything needed to configure IAS as a target system in IPS.
  6. Switch to Identity Provisioning browser tab.
  7. Click the Target System icon and click Add.
  8. Specify the following and click Save:
    • Type: Identity Authentication
    • System Name: <name of your choice>
    • Source System: <your Azure AD source system created earlier>
  9. Under Properties, Add the additional properties below and click Save. Take a look at the help guide for the complete list of properties that are possible with Identity Authentication as a target system.
    • Type: HTTP
    • ProxyType: Internet
    • URL: <your IAS tenant URL>
    • Authentication: BasicAuthentication
    • User: <IAS system user> – See step 5 above.
    • Password: <IAS system user password> – See step 5 above.

This completes part 3 of the setup.

Run the source provisioning job

  1. Switch to Source Systems.
  2. Select your source job and click Jobs iconClick Run Now icon to start the Read Job.
  3. Monitor the status of your job under the Job Logs until you see a Success or Failure statusYou will need to navigate away and come back to this page to see the updated status.
  4. View the details of the job execution.  In my case 10 users and 2 groups are created successfully.
  5. Access your target IAS tenant and confirm the users and groups are created successfully.  The screenshot below shows the user that’s created in IAS and setup for one of the groups.  Few things to notice about the users that you just provisioned in IAS:
    1. The mobile phone field is populated with default value for ipsUser_01.  This is expected as we modified our rules to handle this.
    2. EmployeeNumber, Department, City and Country/Region fields are not visible in the IAS user profile. How do we ensure these fields are also populated in IAS user profile?  Answer to this question is in the supplementary section below.
    3. User groups and their members are correctly replicated in IAS.  Groups will not be replicated if you forget to adjust the source transformation rules in for Azure set the parameter to ignore groups to false (see step 9 in Setup Azure AD as a source system in IPS section)

This completes part 4 of the setup.

Supplementary Section:

In the above scenario, certain fields(employee number, department, city, country etc.) were not replicated in IAS user profile.  How do we handle this scenario?  To address this we need to make certain changes to the properties and transformation rules for source and target systems.

  1. Update properties for your source job and add the following:
    • Property:
    • Value: id,mail,userPrincipalName,<additional user attributes as described in MS Graph API>
    • In my case, I set the value for the value to: id,mail,userPrincipalName,employeeId,displayName,givenName,surname,jobTitle,city,companyName,country,businessPhones,mobilePhone,department
  2. Modify the source transformation rules and add the highlighted part to the rules.
  3. The city and country fields also require additional modifications to source system transformation rules.  Rules highlighted in yellow in the screenshot below maps the city field from Azure to the locality field that IAS expects.  The country field in Azure user profile has the country name while IPS expects country code instead.  I’ve added conditions(in red) to check the country name and set the appropriate country code for Canada and United States.
  4. For ensuring the department and employee numbers fields are also populate in IAS user profile, I am going to update the target system transformation rules set for IAS.  Now you can also do handle this in the source transformation rules, but I will do this in the target.  The screenshot below shows the before and after changes I made to rules for employeeNumber and department in IAS target system transformations.

With all the changes here, the user fields in IAS are populated correctly.


Additional Resource:

The IPS help guide is great resource to learn about all the different transformation options that are available.

SCIM API Reference Guide for SAP Cloud Identity – Identity Directory Service

Microsoft Graph API’s Guide


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Gaurav Dey
      Gaurav Dey

      Nice flow!

      Author's profile photo Mouparna Pal
      Mouparna Pal

      Hi Harjeet,


      Nicely explained. Can we map Manager Information from Azure to IAS?




      Author's profile photo Harjeet Judge
      Harjeet Judge
      Blog Post Author

      Hi Mouparna,

      I haven't tested the scenario but it looks the manager field in Azure is somewhat unique, and to retrieve it the MS Graph API call requires you to pass in the userid field to the call to retrieve the manager.

      This would require a secondary call to Graph API and I don't believe IPS does that when it's reading the user information from Azure.


      Author's profile photo Alexander Schaffelke
      Alexander Schaffelke

      Hi Harjeet,


      thank you for sharing! I was wondering if you know, if we could provision the manger out of source SuccessFactors to SAP-IAS userstore using SAP-IPS?


      Kind regards,


      Author's profile photo Harjeet Judge
      Harjeet Judge
      Blog Post Author

      Yes.  See


      Author's profile photo Alexander Schaffelke
      Alexander Schaffelke

      Hi Harjeet,

      thank you for your support! Provided note worked fine!


      Kind regards,


      Author's profile photo Chris Ryan
      Chris Ryan

      Hi Harjeet,

      When it comes to the permissions required in Azure, you Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All. Is it necessary to have the 'Write' portion of those permissions in a scenario where we are not writing anything back to Azure? Curious if you tried this first with User.Read.All only for example.



      Author's profile photo Andreas Würstle
      Andreas Würstle

      Hello Harjeet,

      What is the advantage compared to this integration?

      Here I have a pull from Azure AD to IAS and don't have to run a job in IPS all the time.


      Author's profile photo Timo Renner
      Timo Renner

      Andreas Würstle

      That is a good question. There might be no best answer.

      If you ask MS, then this approach mentioned by you is the best solution. If you ask SAP, then of course this blog describes the best solution. 🙂

      To come to an answer it is useful to have a wider look.
      When you want to use the IAS content in other SAP Cloud solutions (which is very likely), then sooner or later you end up in using IPS either way. Then why using different tools or approaches synchronizing Identity content?

      Another question is if it is sufficient to just transfer the attributes from AAD to IAS via the SCIM API. IPS provides the ability to adjust the content via the Transformation, which can be very useful if the AAD content is not always as expected.

      Best regards,

      Author's profile photo Matthew Shaw
      Matthew Shaw

      Hello Andreas

      The Microsoft tutorial you've mentioned should be disregarded. It won't work. I'm working with Microsoft to have this article removed. It won't work because Azure can't login to SAC via an OAuth client and that's the only way to obtain and refresh the accesstoken. Whilst you could copy/paste an accesstoken and give this to Azure, it won't last very long until it needs renewing and this is where the solution in the tutorial fails. The tutorial also mentioned IPS, but it doesn't setup Azure to use it.

      Instead, you need to use IPS to connect to Azure and pull the users out of Azure into the SAP IAS User directory. Then using another IPS job to push the users from IAS User directory into SAC.

      This blog provides the next step: from IAS to SAC

      Hope this helps, Matthew

      Author's profile photo Luis Eusa Mendia
      Luis Eusa Mendia

      I believe this solution does not synchronize Groups assignments, and the IPS does. In any case, please let me know if you were able to manage that!






      Author's profile photo Luis Eusa Mendia
      Luis Eusa Mendia

      Hello Harjeet,

      Thanks for the blog, is very well explained.

      I was able to configure the IPS transformation and I am able to synchronize the users with their security groups from Azure AD to IAS.  The problem we are having is that this target transformation is removing the group's assignment from the previously locally created user in IAS, that do not exist in Azure, and never will.

      SAP mentioned in a ticket that this is by design.

      Have you seen this?

      Thanks again!

      Luis Eusa.

      Author's profile photo Harjeet Judge
      Harjeet Judge
      Blog Post Author

      Have a look at the IPS documentation: property can be set to handle this scenario.