Fortunately, SAP has delivered a solution for this - here is the documentation: Configure Different Trust Configurations for the Same Identity Authentication Tenant (Azure AD Apps)
In a nutshell, this significantly expands the use case of SAP Identity Authentication as a proxy towards AAD and allows including AAD security policies and further Conditional Access rules - if required for particular IAS applications (trusted Service Providers). That makes the proxy scenario even more attractive :)
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>.accounts.ondemand.com/saml2/idp/acs/<tenantID>.accounts.ondemand.com" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Destination="https://login.microsoftonline.com/bbffd6ff-54e5-498a-8632-xxxxxxxx/saml2"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="http://www.w3.org/2001/04/xmlenc#" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#"> <ns2:Issuer>https://<tenantID>.accounts.ondemand.com</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 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.
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: https://answers.sap.com/questions/628883/multiple-sso-applications-using-ias-as-proxy-to-aa.html
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!