1

I was able to successfully use external authentication with datazen via HTTPWEBREQUEST from code-behind with VB.NET, but I am unclear how to use this with an iframe or even a div. I'm thinking maybe the authorization cookies/token isn't following the iframe around? The datazen starts to load correctly, but then it redirects back to the login page as if it's not being authenticated. Not sure how to do that part, this stuff is pretty new to me and any help would be greatly appreciated!!

Web page errors include:

-OPTIONS url send @ jquery.min.js:19b.extend.ajax @ jquery.min.js:19Viewer.Controls.List.ajax @ Scripts?page=list:35Viewer.Controls.List.load @ Scripts?page=list:35h.callback @ Scripts?page=list:35 VM11664 about:srcdoc:1

XMLHttpRequest cannot load http://datazenserver.com/viewer/jsondata. Response for preflight has invalid HTTP status code 405Scripts?page=list:35

load(): Failed to load JSON data. V…r.C…s.List {version: "2.0", description: "KPI & dashboard list loader & controller", url: "/viewer/jsondata", index: "/viewer/", json: null…}(anonymous function) @ Scripts?page=list:35c @ jquery.min.js:4p.fireWith @ jquery.min.js:4k @ jquery.min.js:19r @ jquery.min.js:19 Scripts?page=list:35

GET http://datazenserver.com/viewer/login 403 (Forbidden)(anonymous function) @ Scripts?page=list:35c @ jquery.min.js:4p.fireWith @ jquery.min.js:4k @ jquery.min.js:19r @ jquery.min.js:19

            ' ''//////////////////////////////////
            Dim myHttpWebRequest As HttpWebRequest = CType(WebRequest.Create("http://datazenserver.com/"), HttpWebRequest)
            myHttpWebRequest.CookieContainer = New System.Net.CookieContainer()

            Dim authInfo As String = Session("Email")


            myHttpWebRequest.AllowAutoRedirect = False

            myHttpWebRequest.Headers.Add("headerkey", authInfo)
            myHttpWebRequest.Headers.Add("Access-Control-Allow-Origin", "*")
            myHttpWebRequest.Headers.Add("Access-Control-Allow-Headers", "Accept, Content-Type, Origin")
            myHttpWebRequest.Headers.Add("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")

            Dim myHttpWebResponse As HttpWebResponse = CType(myHttpWebRequest.GetResponse(), HttpWebResponse)
            Response.AppendHeader("Access-Control-Allow-Origin", "*")

            ' Create a new 'HttpWebRequest' Object to the mentioned URL.

            ' Assign the response object of 'HttpWebRequest' to a 'HttpWebResponse' variable.
 
            Dim streamResponse As Stream = myHttpWebResponse.GetResponseStream()
            Dim streamRead As New StreamReader(streamResponse)


            frame1.Page.Response.AppendHeader("Access-Control-Allow-Origin", "*")
            frame1.Page.Response.AppendHeader("headerkey", authInfo)
            frame1.Attributes("srcdoc") = "<head><base href='http://datazenserver.com/viewer/' target='_blank'/></head>" & streamRead.ReadToEnd()
Luke
  • 15
  • 6

2 Answers2

1

You might have to do more of this client-side, and I don't know whether you'll be able to because of security concerns.

External authentication in Datazen looks something like this:

User-Agent         |  Proxy               |  Server
-------------------|----------------------|------------------------------------
1. /viewer/home   --> 2.  Append header  --> 3.  Check cookie (not present)
                  <-- 5.  Forward        <-- 4.  Redirect to /viewer/login

6. /viewer/login  --> 7.  Append header  --> 8.  Append cookie
                  <-- 10. Forward        <-- 9.  Redirect to /viewer/home

11. /viewer/home  --> 12. Append header  --> 13. Check cookie (valid)
                  <-- 15. Forward        <-- 14. Give content

16. .................. Whatever the user wanted ..........................

So even though you're working off a proxy with a header, you're still getting a cookie back that it uses.

Now, that's just context.

My guess, from your description of the symptoms, is that myHttpWebResponse should have a cookie set (DATAZEN_AUTH_TOKEN, I believe), but it's essentially getting thrown out--you aren't using it anywhere.

You would need to tell your browser client to append that cookie to any subsequent (iframe-based) requests to the domain of your Datazen server, but I don't believe that's possible due to security restrictions. I don't know a whole lot about CORS, though, so there might be a way to permit it.

I don't know whether there's any good way to do what you're looking to do here. At best, I can maybe think of a start to a hack that would work, but I can't even find a good way to make that work, and you really wouldn't want to go there.

Essentially, if you're looking to embed Datazen in an iframe, I would shy away from external authentication. I'd shy away from it regardless, but especially there.

But, if you're absolutely sure you need it over something like ADFS, you'll need some way to get that cookie into your iframe requests.

The only way I can think to make this work would be to put everything on the same domain:

  • www.example.com
  • datazen.example.com (which is probably your proxy)

You could then set a cookie from your response that stores some encrypted (and likely expiring) form of Session("Email"), and passes it back down in your html.

That makes your iframe relatively simple, because you can just tell it to load the viewer home. Something to the effect of:

<iframe src="//datazen.example.com/viewer/home"></iframe>

In your proxy, you'll detect the cookie set by your web server, decrypt the email token, ensure it isn't expired, then set a header on the subsequent request onto the Datazen server.

This could be simplified at a couple places, but this should hold as true as possible to your original implementation, as long as you can mess with DNS settings.

I suppose another version of this could involve passing a parameter to your proxy, and sharing some common encryption key. That would get you past having to be on the same domain.

So if you had something like:

var emailEncrypted = encrypt(Session("Email") + ":somesalt:" + DateTime.UtcNow.ToString("O"));

Then used whatever templating language you want to set your iframe up with:

<iframe src="//{{ customDomain }}/viewer/home?emailkey={{ emailEncrypted }}"></iframe>

Then your proxy detected that emailkey parameter, decrypted it, and checked for expiration, that could work.

Now you'd have a choice to make on how to handle this, because Datazen will give you a 302 to /viewer/login to get a cookie, and you need to make sure to pass the correct emailkey on through that.

  1. What I would do, you could accept that emailkey parameter in your proxy, set a completely new cookie yourself, then watch for that cookie on subsequent requests.

    Although at that point, it would probably be reasonable to switch your external authentication mode to just use cookies. That's probably a better version of this anyway, assuming this is the only place you use Datazen, and you'd be safe to change something so fundamental. That would substantially reduce your business logic.

    But, you wouldn't have to. If you didn't want to change that, you could just check for the cookie, and turn it into a header.

  2. You should do (1), but just for good measure, one thing I'm not sure on, is whether you can pass users directly to /viewer/login to get a cookie from Datazen. Normally you wouldn't, but it seems like you should be able to.

    Assuming it works as expected, you could just swap that URL out for that. As far as I know (although I'd have to double-check this), the header is actually only necessary once, to set up the cookie. So if you did that, you should get the cookie, then not need the URL parameter anymore, so the forced navigation would be no concern.

You'll, of course, want to make sure you've got a good form of encryption there, and the expiration pattern is important. But you should be able to secure that if you do it right.

Matthew Haugen
  • 12,916
  • 5
  • 38
  • 54
  • Yep I was able to get and add the DATAZEN_AUTH_TOKEN cookie to my request/response (after i made this post) which I imagine I did that wrong somewhere as well, but you're right it seems to get lost at some point too. I can see everything in the web response as if I'm authenticated, but I don't know how to correctly handle it. Excuse my novice abilities with this web request stuff. I also tried doing this client side with ajax, but I was never able to get authenticated correctly that way. – Luke Feb 02 '16 at 13:45
  • @Luke I really don't remember the default behavior of cookies in `HttpWebRequest`, but I can imagine if it supported them through the redirects, in which case that would make sense. Your response would have a fully authenticated body, but then you put it in an iframe, and your cookie isn't, of course, passed down with it. I'm really not sure whether there's any reliable way to do this. Unless, I suppose, if you could put everything on the same domain (with subdomains), you could set a cookie and use that on your proxy, or directly for external authentication. That would work. – Matthew Haugen Feb 02 '16 at 20:55
  • @Luke I edited my answer a bit, to add a theory of how this could work. Again, I don't know a ton about CORS, but this should avoid most headaches. At least this is something. For what it's worth, I can tell you to some degree of certainty that this will become too much of a hassle in the long run, and unless you absolutely need it, you probably shouldn't continue down this path. External authentication is being deprecated, and it's barely supported as-is. I understand your use-case, and I believe this should work, but those are my words of warning. – Matthew Haugen Feb 02 '16 at 21:10
  • Is there a way to pass standard datazen authentication credentials? I'm not sure what the point of having external authentication if you can't do anything with it other than read from behind. Even if I have to open another page or load a div with it, thats fine. I'm just trying to prevent our site from having multiple logins. Our current authentication for our site is using a stand alone sql server. Windows authentication is out of the question because we have external customers. – Luke Feb 03 '16 at 15:36
  • @Luke I've edited my answer to include a workflow that might better-suit you. It takes a little more effort to get right, but it shouldn't be anything too extraordinary. – Matthew Haugen Feb 03 '16 at 18:33
  • @Luke In any event, honestly, external authentication was added as a tangential feature for a specific client pre-acquisition. That's why it's never been quite as supported as things like ADFS. That's also why it is, to the absolute best of my knowledge, not supported in SSRS. I mean, when you think of other websites, very few support a true single sign-on scenario. I can log into my app with Facebook, but I can't log into Facebook with my app. Datazen offers it as a convenience, but it's not a perfect system. The best SSO option available is Windows, which as you say, won't work for you. – Matthew Haugen Feb 03 '16 at 18:36
  • Thanks for all your help and attention to this Matthew. The other scenario I attempted to do was to load the login page to the iframe in standard authentication mode, find the username and password fields within the iframe and fill them in automatically and log them in. And I enabled every CORS field that I could find to let me have access to the iframe contents, but still to no avail. =/ And they were both on the same domain too.. – Luke Feb 03 '16 at 21:19
  • @Luke Hmm, yeah, I'm not sure. I've actually never used iframes before, but I know there are a lot of security implications with them. If it is the same domain, doing something with cookies into your proxy should be doable. For all the unsupported External authentication is, it is useful for your specific scenario. – Matthew Haugen Feb 03 '16 at 22:48
0

I ended up just grabbing the username and password fields and entering them in with javascript. But this piece helped me a ton. You have to make sure you set the 

document.domain ='basedomain.com';

in javascript on both sites in order to access the iframe contents else you'll run into the cross-domain issues.

Community
  • 1
  • 1
Luke
  • 15
  • 6