Single sign on to Intranet Apps from Internet Browser Session

[wurzel]

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.

[doodab]

Can't you use a reverse proxy for the rewriting rather than doing it all yourself?

[wurzel]

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

<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

<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

[eek]

OneLogin may help you.
- Web Single sign-on (SSO) for Cloud & SaaS Applications : OneLogin

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.

[Notascooby]

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.

[RasputinDude]

OneLogin may help you.
- Web Single sign-on (SSO) for Cloud & SaaS Applications : OneLogin

[wurzel]

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.