• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Single sign on to Intranet Apps from Internet Browser Session

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Single sign on to Intranet Apps from Internet Browser Session

    Never really done anything like this before.

    Client has a number of web apps hosted internally that they want to expose to external clients over the internet.

    This will be via an ASP.Net MVC portal application (which is where I come in). Portal will use forms authentication & user will get a windows identity once authenticated (forms user name = domain\username) as the internal web apps all use windows authentication. This is the only acceptable model so thin client technology with VPN or using forms authentication across the board is out.


    So far so good but as soon as a user clicks a link to one of these web apps, everything is done in the context of that user's web browser which means nothing to the target app so a 404 error is returned (presumably trying to access as anonymous user).

    I was thinking that instead of a direct link to the target app, the link instead could be a link to an action method on the MVC portal app and the request made under the context of the user's windows id via some kind of proxy class (using HTTPWebRequest). That would work but all the html that gets served up will inevitably be full of relative links to resources etc which will have no context in the scenario of being served up to some remote user's web browser. Again, I could rewrite all these uris and redirect to the portal app and have it make the requests in the same way as the original page was served up but that's a hell of a lot of hoops to jump through just to get this working (though there's an IIS url rewrite module that looks pretty good if it does what it says it does).

    Am I making a rod for my own back here? Can't help feeling there must be an easier way of doing it other than this.

    #2
    OneLogin may help you.
    - Web Single sign-on (SSO) for Cloud & SaaS Applications : OneLogin
    Last edited by RasputinDude; 25 April 2013, 08:16. Reason: typo

    Comment


      #3
      Originally posted by wurzel View Post
      Never really done anything like this before.

      Client has a number of web apps hosted internally that they want to expose to external clients over the internet.

      This will be via an ASP.Net MVC portal application (which is where I come in). Portal will use forms authentication & user will get a windows identity once authenticated (forms user name = domain\username) as the internal web apps all use windows authentication. This is the only acceptable model so thin client technology with VPN or using forms authentication across the board is out.


      So far so good but as soon as a user clicks a link to one of these web apps, everything is done in the context of that user's web browser which means nothing to the target app so a 404 error is returned (presumably trying to access as anonymous user).

      I was thinking that instead of a direct link to the target app, the link instead could be a link to an action method on the MVC portal app and the request made under the context of the user's windows id via some kind of proxy class (using HTTPWebRequest). That would work but all the html that gets served up will inevitably be full of relative links to resources etc which will have no context in the scenario of being served up to some remote user's web browser. Again, I could rewrite all these uris and redirect to the portal app and have it make the requests in the same way as the original page was served up but that's a hell of a lot of hoops to jump through just to get this working (though there's an IIS url rewrite module that looks pretty good if it does what it says it does).

      Am I making a rod for my own back here? Can't help feeling there must be an easier way of doing it other than this.
      Are the relative links not relative to the application / web server and not the browser?
      Easiest thing is to have a custom cookie that you need to look for if you're application is using NTLM, so search for the cookie first, obviously you need to make sure all these users have valid active directory accounts and you could read the user's roles from there to determine which applications / permission the user is entitled to.

      Issues come about trying to prevent multiple log-ins or if the user closes the browser without logging out, so you need a way to invalidate the previous cookie when a user logs back on.

      Or as mentioned - buy a 3rd party product.
      Anti-bedwetting advice

      Comment


        #4
        Originally posted by RasputinDude View Post
        also microsoft azure have a similar offering which Microsoft are trying to roll or force on everyone.

        As a separate approach use a browser (Chrome or Firefox does I can't remember which one) that requires you to login to the domain when you visit the internal apps and see how that handles things. If the SSO is login you to sso.yourdomain.com and the internal apps are apps.yourdomain.com the SSO information isn't being made available correctly.
        merely at clientco for the entertainment

        Comment


          #5
          Originally posted by Notascooby View Post
          Are the relative links not relative to the application / web server and not the browser?
          Easiest thing is to have a custom cookie that you need to look for if you're application is using NTLM, so search for the cookie first, obviously you need to make sure all these users have valid active directory accounts and you could read the user's roles from there to determine which applications / permission the user is entitled to.

          Issues come about trying to prevent multiple log-ins or if the user closes the browser without logging out, so you need a way to invalidate the previous cookie when a user logs back on.

          Or as mentioned - buy a 3rd party product.
          Yes - using NTLM - all users have valid AD accounts & we're using role based security for access to the apps. That side of things is ok.

          It's the rendered response output from the HTTPWebResponse that is problematic.
          A line like
          Code:
          <script src="/scripts/cuk.js">
          works in the context of the application/web server but not when it's spewed out as a load of static html to some web browser out there on the internet by my proxy class. I guess I'll have to rewrite all these links as
          Code:
          <script src="domain.com/scripts/cuk.js">
          .

          I think the responses suggesting that I use 3rd party apps suggest that this isn't a trivial task & I'm not missing anything glaringly obvious here.

          Edit: One thing I haven't made clear is that none of these apps has any API or web service interface at all - what I'm doing here is a screen scraping approach really
          Last edited by wurzel; 25 April 2013, 08:57.

          Comment


            #6
            Can't you use a reverse proxy for the rewriting rather than doing it all yourself?
            While you're waiting, read the free novel we sent you. It's a Spanish story about a guy named 'Manual.'

            Comment


              #7
              Originally posted by doodab View Post
              Can't you use a reverse proxy for the rewriting rather than doing it all yourself?
              Was just looking into that.

              Got a lot of relative links in JSON responses that need fixing too - not sure how that happens with that approach.

              Comment

              Working...
              X