Azure Application Proxy URL redirect or different internal/external URL

%3CLINGO-SUB%20id%3D%22lingo-sub-65525%22%20slang%3D%22en-US%22%3EAzure%20Application%20Proxy%20URL%20redirect%20or%20different%20internal%2Fexternal%20URL%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-65525%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnother%20Application%20Proxy%20question%20%5Co%2F%20yay%20i%20hear%20you%20cry.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EToday%20i'm%20wondering%20if%20we%20can%20provide%20the%20following%20functionality%20through%20Application%20Proxy..%3C%2FP%3E%3CP%3Eredirecting%2C%20or%20using%20a%20separate%20internal%20and%20external%20URL.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20example%2C%20say%20you%20are%20publishing%20a%20webapp%2Fpage%2Fsite%20whatever%20on%20a%20multi%20purpose%20web%20host%2C%20or%20you%20just%20want%20to%20publish%20a%20certain%20vdir%20as%20the%20root%2C%20so%20someone%20would%20visit%20%3CA%20href%3D%22https%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2F%3C%2FA%3E%20and%20in%20the%20backend%20they%20may%20be%20sent%20to%2C%20on%20the%20web%20server%20%3CA%20href%3D%22http%3A%2F%2Finternalwebapp.internal%2Fsomevdir%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttp%3A%2F%2Finternalwebapp.internal%2Fsomevdir%2F%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eis%20this%20possible%3F%20the%20option%20to%20edit%20the%20external%20URL%20is%20greyed%20out%20and%20just%20copies%20what%20is%20put%20in%20the%20internalURL%2C%20resulting%20in%20needing%20to%20visit%20%3CA%20href%3D%22https%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2Fsomevdir%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2Fsomevdir%2F%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ean%20alternate%20to%20this%20would%20be%20to%20allow%20redirects%20at%20the%20proxy%2C%20so%20hitting%20%3CA%20href%3D%22https%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2F%3C%2FA%3E%20would%20then%20throw%20you%20over%20to%20%3CA%20href%3D%22https%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2Fsomevdir%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsomewebapp-tenancy.msappproxy.net%2Fsomevdir%2F%3C%2FA%3E%20with%20no%20user%20intervention%20or%20need%20for%20them%20to%20recall%20which%20vdir%20they%20require%20(or%20losing%20their%20bookmar%20and%20all%20emails%20with%20provided%20links%20in)%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eor...%20is%20this%20sort%20of%20internal%20path%20mapping%2Frouting%20fudge%20more%20of%20a%20no-no%20now%20and%20its%20a%20step%20towards%20trying%20to%20remove%20convoluted%20sillyness%2Ffudges%20to%20overcome%20bad%20practice%20on%20the%20web%20server%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards%3C%2FP%3E%3CP%3EPete%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-65525%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EApp%20Services%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAzure%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-74016%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20Application%20Proxy%20URL%20redirect%20or%20different%20internal%2Fexternal%20URL%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-74016%22%20slang%3D%22en-US%22%3Ejust%20an%20FYI%20for%20anyone%20interested.%3CBR%20%2F%3Eit%20seems%20that%20this%20is%20currently%20not%20an%20available%20feature%20for%20either%20AADAP%20or%20Application%20Gateway.%3CBR%20%2F%3EHTTP%20to%20HTTP%20redirect%2C%20or%20URL%20rewrites%20are%20noted%20as%20in%20development%20for%20Application%20Gateway%2C%20I've%20not%20spotted%20any%20development%20on%20the%20AADAP%20front%20with%20regard%20to%20this%20features.%3CBR%20%2F%3E%3CBR%20%2F%3Eso%2C%20it%20seems%20that%20the%20minimum%20topology%20likely%20to%20be%20required%20to%20replace%20ISA%2FTMG%20in%20a%20like%20for%20like%20within%20Azure%20services%20is%3A%3CBR%20%2F%3E%3CBR%20%2F%3EAADAP%20(client%20facing%20front%20end%2C%20authentication)%3CBR%20%2F%3EAzure%20Load%20balancer%3CBR%20%2F%3EIIS%20ARR%20(load%20balancing%2C%20redirects%2C%20rewrites)%3CBR%20%2F%3E%3CBR%20%2F%3Eonce%20AAG%20supports%20redirects%20and%20re-writes%20we%20can%20then%20at%20least%20get%20shot%20of%20the%20IIS%20ARR%20machines%20and%20make%20it%3A%3CBR%20%2F%3E%3CBR%20%2F%3EAADAP%3CBR%20%2F%3EAAG%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E
Highlighted
Contributor

Hi,

 

Another Application Proxy question \o/ yay i hear you cry.

 

Today i'm wondering if we can provide the following functionality through Application Proxy..

redirecting, or using a separate internal and external URL.

 

For example, say you are publishing a webapp/page/site whatever on a multi purpose web host, or you just want to publish a certain vdir as the root, so someone would visit https://somewebapp-tenancy.msappproxy.net/ and in the backend they may be sent to, on the web server http://internalwebapp.internal/somevdir/

 

is this possible? the option to edit the external URL is greyed out and just copies what is put in the internalURL, resulting in needing to visit https://somewebapp-tenancy.msappproxy.net/somevdir/

 

an alternate to this would be to allow redirects at the proxy, so hitting https://somewebapp-tenancy.msappproxy.net/ would then throw you over to https://somewebapp-tenancy.msappproxy.net/somevdir/ with no user intervention or need for them to recall which vdir they require (or losing their bookmar and all emails with provided links in)?

 

or... is this sort of internal path mapping/routing fudge more of a no-no now and its a step towards trying to remove convoluted sillyness/fudges to overcome bad practice on the web server?

 

Regards

Pete

1 Reply
Highlighted
just an FYI for anyone interested.
it seems that this is currently not an available feature for either AADAP or Application Gateway.
HTTP to HTTP redirect, or URL rewrites are noted as in development for Application Gateway, I've not spotted any development on the AADAP front with regard to this features.

so, it seems that the minimum topology likely to be required to replace ISA/TMG in a like for like within Azure services is:

AADAP (client facing front end, authentication)
Azure Load balancer
IIS ARR (load balancing, redirects, rewrites)

once AAG supports redirects and re-writes we can then at least get shot of the IIS ARR machines and make it:

AADAP
AAG