New conditional access options and self-service for proxy applications


We have recently added two new capabilities to Azure Active Directory that apply also for proxy applications:

More conditional access options

Conditional access to application means that you can apply application specific policies that are evaluated each time a user is trying to access the application. In this release we have added the ability to block access to applications when users are not located at their workplace based on their source IP address. Customers asked for this as they are deploying applications on separated cloud environments and they want to make these applications securely accessible to their employees without exposing them to the Internet. In the past, companies deployed expensive VPN to their cloud environment and had to deploy dedicated filtering solutions.

We keep working on adding more conditions to allow you to set more types of policies.

See more details here: http://blogs.technet.com/b/ad/archive/2015/06/25/azure-ad-conditional-access-preview-update-more-apps-and-blocking-access-for-users-not-at-work.aspx

Self-service access requests

Self service application access allow you to streamline the process of enrolling new users to applications. Instead of users making expensive support calls to your helpdesk, they can now find and request access to applications by themselves using the access panel portal. The approval process can be delegated to people in your organization that owns these applications. This is done without compromising on security and leaving the IT organization under control with full visibility, reporting and auditing of these actions. You can now apply all these capabilities also to on-prem applications and have a fully self-service process in minutes without deploying expensive on-prem tools. This is another benefit that Azure Active Directory can bring to your legacy on-prem applications without changing them.

See more details here: http://blogs.technet.com/b/ad/archive/2015/04/23/employee-self-service-app-access-for-azure-ad-now-in-preview.aspx

Comments (4)

  1. Stewart says:

    Hello,

    We’ve started using this product and have a question about whether it’s possible to have a different external URL than the internal one. At the moment it seems they are coupled, to have an external URL of
    https://app.domain.com/app1 means you have to an internal one of
    https://inside.dnsname.com/app1 when we want this inside URL just to be
    https://inside.dnsname.com/ (as many of our apps are in the root of the web server)

    Is this feature a possibility soon / ever?

    Cheers

  2. MeirM says:

    Hi Stewart,
    App Proxy does not change the application payload and therefore, does not change the path part of the URL. Many applications break when you try to do that. In the past, there was an advantage of using a single external domain which is not true anymore. Our
    customers are using many external domains (we have a customer with 48). Therefore, this feature exist in our old products (TMG/UAG) and not in the new ones.

    Thanks,
    Meir

  3. Stewart says:

    Hi Meir,

    Thanks for your comments. I do not agree with some of your sentiments however! With HTTPS certificates costing about £400 through our prefred supplier, having a domain for each app such as app1.domain.com, app2.domain.com just isn’t practical. In addition to
    the cost, you have the administrative overhead of having to manage all of these certificates. This limitation in the product forces our hand a little, and means we will have to use the native msappproxy.net address – it’ll work but our band is important and
    means users will not see our domain when accessing our applications.

    Thanks

  4. MeirM says:

    Stewart,
    App Proxy do support wildcard and SAN certificates that mitigate the difficulty and cost around certificate issuing. We are listening to your asks and will consider this in the future.

    Meir

Skip to main content