Currently we just begin to use an application called "etran". This application requires user name and password to login. Now, my assignment is to integrate etran application in our internal application. This means that somewhere in our internal application, there is a link leads to the etran application.
It is going to be single sign on, that means that once user logs into our internal application, when he/she clicks on the etran link, no sign on to etran is needed.
I consult with the technical people in etran. they said that our internal application needs to send a "login request" to etran via SSL with the user's information encoded in base 64 format. etran captures the HTTP header containing user authentication and authorization information, and parses the required information from the HTTP header.
My question is that how I set user information in HTTP header? From my understanding, once I am able to set the user information in HTTP header, it is in base 64 format?
Thanks in advance for your help.
Unless etran will allow a user to be logged in via some type of session id or login token in the url, you aren't going to be able to log them in that way. Most web applications maintain login state via a cookie, and you can't set a cookie for a domain other than your own. Although, them saying send the info via http header base64 encoded sounds like http authentication. You need thier browser to send the login request in either case unless they allow session id's via url.
There seems to be some missing hole in your info.
- Do you guys share user id/password? even if you pass the credential through https, what password are you going to send? the password to login to your application?
This seems to be weird to me at least. If the password is different for both application, then to get this around maybe more complex.
I would ask them if they are using LDAP. I don't know too much about LDAP but it handles the SSO for our application.
I would never use hidden / pre-populate user/password fields for obvious reasons.
Give us more info on this and I'll give more detail help
Thank you very much for both of your replies. I am really appreciated for your help.
etran has already something built to parse the HTTP Header, so I believe the only choice I have is to through HTTP authentication, not the form authentication.
yes. sorry for the missing information.
According to etran, they just need the user name, not password, but they need more infor of the user in addition to the user name, so in both databases, the user information must be the same to be authenticated.
i need to pass base 64 format to etran (I don't know if I should encode it or it is going to be encoded automatically through HTTP protocol if it is set in HTTP header) like the following:
I have used some online base 64 encode/decode tools, and I found that after decoding, the following XML format is presented. It will etran's task to decode the base 64 string and parse the info.
to reverse engineer, maybe I need to encode user info into base 64 from xml string like above (by the way, UserXSPRole, SecurityID1...RecipType1-RecipCode1... are all business realted information).
Anyway, I think the first step is to figure out how to set up custom HTTP header and pass it to etran. Later I may need to figure out how to set up the base 64 string manually from xml format (not sure if I have a xml format string and set it to HTTP header, HTTP protocol is going to convert it to base 64 format).
I have done some research, and found out that I may need to go through the following approches:
I can not set custom HTTP header inside a requst. I may need to set up a new http request from servlet, but I don't know how.
I am stucked with all approaches mentioned above, and don't even know if they are correct ways to go.
I hope I make myself clear, sorry if I make you confused.
do you have any idea?
I'm 99% sure this would be possible solution. When a user clicks the link, forward it to the Servlet and redirect it. In the Servlet class, you can easily set HTTP headers.
Yes, you can set http headers by using the XMLHTTPRequest object, but this still won't work due to security constraints in web browsers. Web browsers adhere to a same domain policy for the XMLHTTPRequest object, and will not allow an XMLHTTPRequest to send a request to a different domain. It will throw a security exception and fail.
You can't have your webserver send this header along with a location(redirect) header. The browser will happily follow the redirect, but there's no way to tell it what http headers to send along with it.
While you could just have your webserver send the request straight to etran along with the required headers, all you have accomplished is logging your webserver in as that user. That probably does you no good unless you plan to be a proxy.
You need to figure out what info the web browser is expected to send to etran in each http request in order for it to continue to be recognized as being "logged in". An easy way to do this is to just log in in your web browser, and view the http headers being sent.
I think crmalibu is correct. Perhaps, the only way is to attach the URI as part of redirect URL. You're going to lose security out the water though....
Seems like unless you guys share the same domain name, it will be very difficult to perform SSO.
In a way, if you have control to your proxy server then you can use Proxy bypass trick to think it's the same domain name.
One more post.
There's another way to do this way as well. If "etran" app can use "referer" field from the HTTP Request, then they can authenticate using this way. Obviously, "etran" will only validate if it came from your application and no other. So, if you use "redirect" from the server than the "referer" value should have IP address of your application. To me, this sounds good.
Of course, this would mean code change on "etran".... g'luck w/ that!
thank you so much guys!!
I really don't want etran to change their code at this point. If I pass the info through the URL, In addition of losing security, etran will need to change the code, too. right?
I am not familiar with proxy, can anyone explain a little bit more in detail how this can work?
is it the only way right now?
thanks again for your kind responses.
etran will need to pass back a short lived token of some sort so that the client can be redirected with that token in the url.
- Client makes a call to Your Server asking to be redirected to Etran's Server.
- Your Server makes an HttpRequest (possibly using HttpClient) with the correct headers to Etran's Server.
- Etran's Server will then generate a short lived token and return that token to Your Server.
- Your Server will then respond to the Client with a redirect to Etran's Server with the appropriate token in the request url.
You could also ask etran how they expect the interaction to go. I don't think it is reasonable for them to always expect the request header to have the security information coming from the browser. If they do, ask them how that works.
I've had to interact with several outside services like this and they have always been quite helpful once asked.
Best of Luck.
proxying the html/http messages is a ton of work, and the result would likely be very fragile. You almost certainly don't want to do this. The session id or login token in the url is your only real hope here.
just to confirm that the 2 approaches that you mentioned will involve code changes on the etran side, right?
We most likely could not figure out if the solutions we purposed will cause code changes on their end.
I think what we're saying is that it is unreasonable of etran to only expect the one call to sign in from a clients browser.
My bet is that sending the request to the etran site with the encrypted header and then they will send you back a token that you will send back to your client.
HOWEVER, if etran does expect the single request with the information in the header, then the token solution that has been batted around in this thread would cause etran to change their code.
These are the things I think you should be asking etran (since we do not have their documentation):
Could you explain the entire process of a customer coming to our site and then seamlessly signing-on to your site (fully and completely until I fully understand what you're saying)?
If we are not sharing a token how would you recommend getting the header information to the web browser?
Why are we encrypting things in the header? Isn't the initial request going to be going over https?
I'm sure there some other interesting questions in there, but these are the most important.
Just make sure that you ask them. It sounds like your company is partnering with their company and it would be in EVERYONEs best interest if everything goes smoothly.
Best of Luck.
I use httpclient (initiate a new request) in my servlet and I am able to send the cutom http headers, and I am able to login automatically, but I still have some problems
The flow is that UserLogin. aspx --> default.aspx --> SearchByCorpation.aspx
The UserLogin page gets the headers and redirects to SearchByCorpation page and send the response back.
I display the content of the SearchByCorpation page on the browser by using the following code:
The problem is that all images, styles and functionalities are not working. I believe it is because it is using relative path on etran application, but in fact it is looking images, styles and functionalities under my localhost, and they are not in my application context.
I have a work around for images and styles, but not functionalities. I want all requests on etran server once they are on SearchByCorpation page. I think I can use redirect to accomplish that, but my problem is that I can not sent custom http headers with redirect. I really need to send http headers to do automatic login(single sign on).
I am really stuck right now. any thoughts? I am really appreciated.
This will be very tough to make it work. You do not want to login at servlet level. You want to login at client level (aka browser). Anyways, you're in a spiral path of failure right now. As suggested above, you need their co-operation to make it work.
This topic is now closed. New replies are no longer allowed.