Referring the Prisma Access Mobile User documentation https://www.paloaltonetworks.com/resources/guides/prisma-access-for-users-deployment-guide
Page-88 specify that wildcard must be used to configure the SAML Azure Enterprise Application (SSO config) :
|Step 13: In the next Identifier (Entity ID) box, enter https://*.gw.gpcloudservice.com:443/SAML20/SP.|
|Step 14: In the Reply URL (Assertion Consumer Service URL) box, enter https://*.gpcloudservice.com:443/SAML20/|
However, the wildcard utilization seems to not be supported (or not anymore supported) by Azure SAML configuration. I tried using the APP Registration "manifest" tool, and adding the wildcard "URI" within the JSON with NO SUCCESS. The only way that I make it worked, was by configuring the complete gateway URI, which is not scalable since "a lot of gateways" !!
Any clue on this, or have you heard something about it ?
I have checked on Azure's documentation and unfortunately, they don't mention whether they support wildcards or not.
From their website:
Basic SAML Configuration setting SP-Initiated idP-Initiated Description
|Identifier (Entity ID)||Required for some apps||Required for some apps||Uniquely identifies the application. Azure AD sends the identifier to the application as the Audience parameter of the SAML token. The application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. Enter a URL that uses the following pattern: 'https://.contoso.com' You can find this value as the Issuer element in the AuthnRequest (SAML request) sent by the application.|
|Reply URL||Required||Required||Specifies where the application expects to receive the SAML token. The reply URL is also referred to as the Assertion Consumer Service (ACS) URL. You can use the additional reply URL fields to specify multiple reply URLs. For example, you might need additional reply URLs for multiple subdomains. Or, for testing purposes you can specify multiple reply URLs (local host and public URLs) at one time.|
This seems to be an azure configuration limitation. Hence, I would encourage you to check with them.
My thought is that should be to Palo-Alto to validate with Microsoft and make sure that proposed solution still work as documented.
I have open a CASE with Palo by the way...
I have been told by Palo TAC there is an opened issue with Microsoft/Azure to find solution about the "wildcard" URL within the Azure SAML config (Identifier Entity ID) that's look like no more supported in Azure.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!