Skip to Content

IAS as a proxy to Azure - specific customer requirements for Azure Conditional Access

Hello together!

The following question requires some additional background information and context, so let's start.


The corporate IT security department responsible for authentication, dictate to use Microsoft Azure Active Directory as the primary corporate identity provider to authenticate all users… and devices for all corporate web applications.

It is important to note that most SAP cloud applications will only trust SAP Identity Authentication (IAS) as their primary SAML identity provider, which means SAP Identity Authentication is mandatory to access SAP cloud applications. This way IAS is seen (and often used) as a central hub for the connected SAP applications.

But how to check for managed devices and use other security features that Azure provides when accessing SAP applications? Fortunately, there is an integration of the IAS as a proxy to Azure. The target is to provide single sign-on (SSO) between applications using Azure AD as an authenticating identity provider and applications using Identity Authentication as a proxy identity provider. Thereby all known security functions such as conditional access and MFA still can be used when accessing SAP applications.

In typical customer scenarios, a large number of service providers (so-called enterprise applications) may exist within the Azure Active Directory. Now a given tenant of the SAP Identity Authentication Service is one of them. It is significant to understand that from the perspective of Microsoft Azure Active Directory, the IAS is just one service provider. And this will become an important point to understand the challenge.

Once the Corporate IdP has been configured for a given application (some or all) there is another SAML AuthnRequest (example below) that is forwarded to the Azure destination.

<AuthnRequestAssertionConsumerServiceURL="https://<tenantID><tenantID>" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Destination=""ID="Sxxxxx51-c451-4xxb-8xx0b-ffexxxxxx5" IssueInstant="2020-09-30T18:38:56.113Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="" xmlns:ns3=""> <ns2:Issuer>https://<tenantID></ns2:Issuer> <NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></AuthnRequest>

Azure AD uses the ID attribute (random) to populate the InResponseTo attribute of the returned response. The Issuer element in the AuthnRequest matches the App ID URI specified during application registration (Entity ID).

That makes it impossible for Azure to understand which of the many applications (SPs) maintained in IAS, are used. For Azure, it is just an authentication request from the issuer IAS. There is no information about the concrete SAP cloud or on-premises application that may require special authentication rules. What do you think, isn’t that an issue. For most organizations that must not be the case, for others it is.

Now you go ahead and set up SuccessFactors (here IAS is needed anyhow), some SCP Subaccounts, and some On-Premise S/4HANA systems to trust and use IAS as the IdP. Besides, the company has the requirement to separate between company managed devices (let us say using Microsoft Intune) or private devices (any other devices). Based on this, Azure should allow access according to the rules implemented via conditional access. Guidelines for conditional access are enforced after completion of the first-factor authentication, which is usually a successful login in Azure. Conditional access is therefore at the heart of the identity-driven control level. Such guidelines are like simple “if-then instructions”. If a user wants to access a resource, he has to fulfill certain conditions that relate to the device (that is required here), the IP-geolocation, the user, or his group memberships, the target application (important as well!!), and other factors. The actual access decision or the need for additional authentication (MFA) is then made based on this check.

The Requirement

The company needs to check the device status for any SAP application in use. Now they are faced with integrating access to SAP applications (on-premise or cloud) into this process. A question and requirement that came up yesterday during an SAP security workshop with a customer. He likes to restrict access to specific SAP cloud or on-premise applications and to allow private (non-managed) devices only for some target applications. Let us say access to SFSF should only work for users with managed company-devices, while access to a central SAP Fiori Launchpad should be possible from any device.

By default, most of the corporate applications require a managed device to pass the Azure doorman. Without knowing the respective application, how can such a configuration be implemented with SAP IAS in conjunction with Azure Conditional Access?

Questions and ideas

As of now, it seems to be impossible to set up another corporate identity provider in IAS pointing to the same Azure tenant and thus the same entity ID.

  • Is there a way in Azure to export federation metadata with a different entity ID per enterprise application?
  • Is there a way to populate the application name/ID towards Azure via the AuthnRequest?
  • Is there a way to configure multiple Corporate Identity Providers using the same Azure tenant and perhaps then map the applications one-to-one?

Let us say you could create in Azure one enterprise application for each IAS application that has individual conditional access rules and device requirements. Within the IAS application configuration, you select the corresponding default identity provider in each application. If Azure or IAS would allow that it would help to achieve the desired goal. Azure now would understand the specific target application.

Do you have any ideas on how to meet this requirement? And please don't come up with multiple Azure tenants or the likes, that isn’t a serious solution :-)

BTW: here is a similar question:

Suggestions and tips are always welcome!

If no solution can be found on this channel, we would communicate the whole thing to SAP with the support of the customer. Thank you!

Cheers Colt

Add a comment
10|10000 characters needed characters exceeded

  • Hi Carsten,

    my understanding:
    The priority of SAP is to carve-out authentication functionality from their cloud products and delegate that to IAS tenants. They want to get rid of maintaining all the authentication options on their different cloud platforms.

    They sacrifice the concept of one central IAS per company for this priority.

    So the answer seems to me: use multiple IAS tenants for different authentication requirements. Since SAP gives away IAS tenants bundled to their cloud products for free, this should not be an issue financially.

    From an architectural point of view this is may be less than beautiful, of course.

    Regards, Lutz

  • Just to comment on Lutz's message, SAP gives 1 prod and 1 test tenant per customer, regardless of the number of products used. Additional tenants have to be purchased separately.

  • Hi Lutz and Lucas,

    thank you for your answers. That is a possible workaround, yes ;)

    Unless SAP is planning to integrate this as a feature or the customer is not actively promoting this, I would see it that way. Operation of an IAS tenant on which all SPs (applications) are created that should be accessible to external users. A second one for SPs that are only accessible for corporate devices.

    Cheers Colt

Related questions

1 Answer

  • Posted on Oct 19 at 03:24 PM

    Michael! Well, I support the concept of SAP and the introduction of SAP Identity Authentication. I also understand the added value and use of IAS as a central authentication hub.

    Only in very specific scenarios as described in my post, however, SAP should make improvements, the integration of SAP IAS into Azure AD should be possible on an application-level not only "system-wide".


    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.