Suppose you have some awesome analytics tool that provides great value to a bank's customer, but
they need to interact with it through the bank's website, and you need to host the tool.
You already have the data you need for the analytics to work, and the only missing piece you're left
to consider is "how do I know to whom to show which data?"
The data is private, so you need to ensure you're not showing it to someone who's not authorized to see it.
Photo by pbkwee
Some more constraints:
-
You don't want to generate thousands of usernames and passwords that would create more burden for the
users (and force them to log in twice)
-
You can't hook into the bank's user system. (nor would you want to, since they'd still have to log in twice)
-
You want this to be reasonably simple for the bank to implement whatever they need to do to make it
work on their end.
To show it on their site, you decide to create a template-less app that they'll embed in an iframe.
So what authorization mechanism do you use to know who should see which data?
One idea I had was to simply restrict which IP addresses (to those of the bank) the app would respond to.
Then they could just request a page via HTTP and serve up our response. But in order to get that to work,
there's too much that needs to be done: we have to coordinate all URLs with whatever the bank decides
they should be, and they have to figure out whether to GET, POST, PUT, etc. back to us.
The next idea was to have a single page that is restricted by IP address (to those of the bank), where
they will make an HTTP request to receive a token that expires after some length of time (or at the bank's
request, if they hit another URL to invalidate the token). The bank includes the token in the iframe src
URL which lets you know whose data to show.
But I'm really interested in hearing your thoughts.
How would you do it? Is there a
standard way of doing this already?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
When user log in he gets token, on every request you pass token as parameter and based on token you decide will you return wanted info
Posted by Rocco
on Dec 09, 2011 at 12:43 PM UTC - 6 hrs
The problem I see there is that anyone who got that link now has a valid token, and can then see info they shouldn't be seeing.
Posted by
Sammy Larbi
on Dec 09, 2011 at 01:18 PM UTC - 6 hrs
I considered OAuth, but felt it would be too much hassle for the bank in this case to be their own OAuth provider.
However, after a little prodding from one of my friends on twitter, I did some looking and it seems there are enough libraries out there for server and client side that it might not be as much work to become their own provider as I originally thought.
Still interested in hearing more suggestions though!
Posted by
Sammy Larbi
on Dec 09, 2011 at 01:20 PM UTC - 6 hrs
I would have to second Oauth.
Have you looked into how Wesabe did it? They opensourced a lot of the code when they went belly up.
Posted by
SeanJA
on Dec 19, 2011 at 11:12 PM UTC - 6 hrs
Cool, I didn't realize Wesabe open sourced their stuff.
For anyone who's interested, see
https://github.com/wesabe/ssuHowever in my case, "bank" is just a dummy system to stand in for "a place where the data needs to remain secure, because it's very sensitive."
Posted by
Sammy Larbi
on Dec 20, 2011 at 05:52 AM UTC - 6 hrs
Well, it's a difficult question. Personal data protection is an important issue web developers have to deal with nowadays. There a variety of techniques they could use. There are a few of them I could recommend, but I'm not sure I can share my knowledge here.
Posted by microsoft dynamics ax
on Jul 28, 2016 at 02:40 AM UTC - 6 hrs
Leave a comment
