On a tomcat-7 instance I have ApplicationA, ApplicationB and SSO vavle turned on. Both applications are servlet-based and secured with form security method.
When I use web browser, SSO works as intended: when I open ApplicationA for the first time, I'm prompted to enter username and login. After I pass login form I can access ApplicatioB without being asked to login.
Now the usecase is: ApplicationA needs to request some content from ApplicationB. So I open ApplicationA in web browser and enter login and password in a login form. After that ApplicationA creates HttpUrlConntection to ApplicationB to get some content but it only gets ApplicationB's login form instead as it is a new request which is not authenticated.
I expect ApplicationB to be accessed for a programmatic request from ApplicationA without login form because I've logged into SSO in a browser.
Also I need content from ApplicationB as a String in ApplicationA, so I'm not using requestDispatcher.include().
Is it possible?
What I tried is to set all Cookies (there are things like JSESSIONID and JSESSIONIDSSO) and headers from my browser request to HttpUrlConnection via conn.setRequestProperty() but no luck.
When a servlet makes an Http request to an external Http service - even when that service is on the same webserver - the identify of the requester is the servlet application, not the servlet's remote user.
I don't know offhand if there is anything in the current JEE spec that would allow server-side code to assume a remote user's identity. Very possibly there is not.
To avoid that problem it's best to have the referencing webapp authenticate itself to the secondary webapp. And to avoid having to deal internally with logins, that would probably be best done by setting up a client certificate for the in-between webapp.
A side effect of that is the the intermediary webapp must have the greatest-common-denominator security rights of all possible remote users and must therefore handle ensuring that a given remote user isn't supplied with information to which it isn't authorized.
A simpler way to handle this if the intermediate servlet does not itself need to process data from the secondary servlet is to set up the client's webpage with URLs that pull the desired content directly from the secondary server. That's especially workable since SSO has already guaranteed authentication and therefore you don't get into such awkward situations as having a login form pop up where a chunk of CSS should be loaded.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
Did you ever grow anything in the garden of your mind? - Fred Rogers. Tiny ad: