IPS cookie truncated if domain name starts with 't'. - ONE Portal Server 3(Archived)

I'm using iPlanet version 3.0, service pack 3.0, hot patch 3.0. I have a scraper channel that's configured to scrape a JSP that also resides on the portal server. The portal is set up to serve numerous domains, and we have 'remember me' functionality enabled so people can cookie in.
Everything works fine, provided the portal domain name does not begin with the letter 't'. If someone cookies in from a domain that begins with the letter 't', they successfully bypass login, and the portal home page is properly displayed with all the appropriate content. But the (secondary) request from the scraper channel to scrape the on-board JSP fails authentication, resulting in the sign in error page being displayed in the scraper channel (effectively as scraped content ... isn't that ironic).
By introducing degbug statements to dump the cookies attached to each inbound request, I've determined that, when the cookie is read for the secondary request (to the on-board JSP), the IPS cookie is being truncated. As a consequence, the authentication software can't locate a valid (active) session, and authentication fails. I've confirmed that this only happens for users attempting to cookie in to domains that begin with the letter 't'.
More detail: the IPS cookie (which includes the domain name) is obfuscated using a simple character substitution algorithm ... an obfuscated cookie looks something like this:
The character substitution algorithm replaces 't' with 'g' ... in the example above, 'greevy.pbz' is the obfuscated domain. The cookie for any domain that begins with the letter 't' therefore contains the sub-string '%25/g' (confirmed through examination of numerous cookies). The cookie is being truncated at this point ... the cookie string above, for example, is truncated as follows:
A cookie containing this string works fine for the initial request to the portal server. But the secondary request to the JSP (from the scraper channel) fails to authenticate because the cookie attached to the scraper request is truncated immediately following the %25. ???
I have not been able to determine whether the cookie is being truncated when it is written (i.e. appended to the request by the scraper channel) or read (when the request to the JSP is being processed. Both the write and read operations take place deep in the bowels of the iPlanet Portal Server code, the former in the URL scraper code, the latter in the authentication, so debugging is a bit of a challenge.
I tried upgrading to Service Pack 5.0, but it didn't fix the problem. I've seen a lot of bug tickets pertaining to cookies, but haven't been able to locate a bug report that identifies this particular problem.
Anyone have a clue?


Setting Cookie Domain

Here was my original problem
We have a website company.com and its sub domain subdomain.company.com, both these have a auto login process for which we use cookies. If a user auto logs into company.com he/she needs to re login to subdomain.company.com as the cookies are not shared.
solution: I added the set domain parameter "company.com" while creating the cookie, now both company.com & subdomain.company.com can share the cookie.
new problem: We have internal testing websites www-t1.company.com, www-t2.company.com and so on and our live website www.company.com, if I create a cookie for company.com domain it would end up being shared by all the testing websites and live website which was undesirable.
new solution: I read the request URL and accordingly create the cookie domains - www-t1.company.com, www-t2.company.com and for the website www.company.com, now the cookies are specifically created for each of the environments.
new problem 2: The browser thinks that www-t1 is a sub domain and prefixes it with a '.' so the new cookies look like .www-t1.company.com, .www-t2.company.com (I didn't get a chance to look at what happens in production as we can't deploy there yet) and www-t1.subdomain.company.com can't share this cookie.
So my question is, is there anyway I can prevent this either by not allowing the browser to prefix my domain with a '.' or by some other means and hence create cookies under my test website www-t1.company.com and not as a sub domain. 
If you want the cookie to cover all subdomains of one domain, then you need to set the cookie domain to ".domain.com" instead of "domain.com". 
Well I was able to successfully share the cookies between all my sub domains (the browser prefixes the period and makes it .domain.com), my issue arised when I wanted to restrict the cookie based on www-t1.domain.com, www-t2.domain.com the resulting cookies considered www-t1 as a sub domain and the cookie was created as .www-t1.domain.com (again the browser prefixed the period but this time it was not desired). 
Ah OK, I see.
If you aren't already using it, add some configuration setting to the webapplication which indicates the development stage of the webapplication. E.g. development, test or production. Based on this you decide how to lookup the cookie. From the domain or the subdomain. 
Well assuming I could do that -
In a non production environment -
1) The domain creates a cookie - lets say .www-t1.domain.com
2) The sub domain will only have access to the cookies under subdomain.domain.com & domain.com but not .www-t1.domain.com.
If instead in step 1 I create the cookie under domain.com then it would be shared between www-t1.domain.com, www-t2.domain.com and so on which is something I am looking to avoid.
I appreciate your help, please let me know if you have any more suggestions. My theory is if I can let the browser know that www-t1 is not a sub domain but a valid www prefix then the cookie would be created under www-t1.domain.com and my requirements would be met i.e. www-t1.subdomain.domain.com would be able to access the cookie and www-t2,t3 and so on won't.

Cookie - Domain vs. Browser URL

I want to set the domain of the cookie. The domain of the server is dev001.company.com. I set the domain of the cookie to .company.com. However, when accessing the application the developer uses https://dev001/app as the URL instead of https://dev001.company.com/app and the cookie is not set. (If I use the second URL the cookie is set.) Is there something I can do to make it work with the first URL?
I ask because we have multiple production servers that are under same domain. (prod1.company.com, prod2.company.com, etc...) So I need to set the domain of the cookie so that all servers have access to the cookie. However, the URL the customer enters into the browser is https://www.myapp.com/app. (Which first runs through a switch to determine which server to use and then is mapped to the server so the customer does not realize they are being redirected.)
I was going to set the domain of the cookie to .company.com so that all the productions servers could access the cookie but fear it will not work because of the URL. Has anyone else experienced this problem, if so what solution did you use.


Hello, I want to use the portal gateway to acces a specific site that uses jsps and servlets, so for this site the Session is sotred in a cookie as JSESSION,
The problem that I have is that when I access the portal I have a JSESSION cookie set with path /amconsole, and when accessing the other application via the portal gateway I get another JSESSION cookie but dwith a path /mypath, so the problem is that when I access the next page from the applciation the broser does not send the JSESSION cookie because the URL has a different path: https:/portalgw.mydomain.com/http://theothersite.mydomain.com/mypath.
Any ideas how to fix this?
Thank you very much.
Hi !
I have seen a case that could be related to this.
Thought this could be of interest......
Pasted it below.
### F�rtydligande ###
As Mr. X said in his email, there is nothing you can do with the
out-of-box URLScraper today. However, if you really really want to have the
cookie re-written in the ways that sprint want, one possible solution is
extend the out-of-box URLScraper channel, and add the cookie handling code in
the custom URLScraper provider. So, it can be done, but not with out-of-box
URLScraper provider.
### F�rtydligande Slut ###
### Original fr�ga med svar "inline" ###
Please see my comments inline. thanks, gang
Andrea Cravens wrote:
Hi! All!
We are experiencing a situation at Sprint where they are trying to
Scrape an application using the URLScraper.
Their application runs on Weblogic 7.0 SP1. We are using portal 6.0
without the Gateway ( Open mode). The URLScraper ( after installing a
patch ) is forwarding the cookies with correct name and wild card
These are the cookies being forwarded and sent to the browser when they
load the desktop:
* ?sprint real estate user?
?.sprint.com? ?/?
* ?cresecurityperimeteratmtoken?
?.sprint.com? ?/?
* ?jsessionid?
?pdasew0a.corp.sprint.com? ?/?
When they click on the link on the Scraped page on the portlet the
Weblogic sends a new jsessionid cookie with fully qualified domain name
* ?jsessionid?
?defaulttrain.corp.sprint.com? ?/?
However this cookie does not get forward with fully qualified domain
name and Weblogic only accepts (expect to read it) with
?defaulttrain.corp.sprint.com? on domain. Since the URLScraper set all
cookies with wild card Weblogic loses its session.
1) does anyone out there ever experienced this issue? how did you solve
it???Nothing could be done currently to solve this.
2) What is the expected behavior of the URLScraper forward cookie
feature? Is it suppose to wild card all cookies? or is it supposed to
forward all cookies as they have been set by the application sending
them???Originally, all cookies from url scraper channels are rewritten to have a
domain of portal server's full host name. Patch 114582-01 changed it to be
the domain name of portal server. This opens the door for the cookies to
be shared by all the other servers inside this domain. This already brings
in some security implications. Keep in mind, those cookies set on the
browser is actually sent from portal server, not from the other web sites,
although url scraped. Your browser will reject cookies with domain set to
anything other than that of the server which send them.
The possible solution is to have a special url scraper channel, which
rewrites all links on the channel. So click on those links, it will go
thru a special gateway to restores the cookies back to the original. If
CU is using SRA, then cookies would be forwarded back without any change.
Of cause, not applicable to the url scraper channel currently. 
I'm curious, Per-Olov, were the emails which you pasted from some sort of Portal mailinglist?
I'd be interested to subscribe to it...
Sun One Portal resources seem to be very rare on the net, so I try to collect what I can :) 
This is from Sun and I think it's actually internal...
So I checked that it did not contain any phone number or names before pasting it on this list.
So... sorry ! U can't subscribe to it.
There is some settings in the portal regarding cookies in the portal to check....
In the admin GUI:
platform->cookie domains
gateway-> Forward cookie URL:s
gateway -> cookie management
In my installation I had to enable "cookie managment" for the Yahoo portlet to work through the gateway.
I tried all options for the cookie management and nothing worked, so what I finally did is to make a channel taht signs the user into the other application and then send the cookie to the broser, but first rewriteing th path for that cookie, changing it fomr /path to /http:/server/path.
But I think that the portal gateway should rewrite the cookies. 
Okay, too bad, but thanks.

CDSSO and custom login post-processing question/issue

I've been using Access Manager plus a web agent on an internal domain, which is being migrated to a new domain. For some time, both will remain operational, with resources under each. The primary 'old' domain resource being protected is SunONE 6.1, the new is a RHEL 4 box/apache, plus an additional app server with custom integration using login post-processing, via Java code plugged in to/opt/SUNWam/lib/ISAuthPostProcess.jar
This is under AM/JES 2005Q4. The 'primary resource' is protected via Policy Agent, and the custom app is protected via redirection from the app itself.
This leads me to enabling the CDSSO servlet. However, I'm uncertain and haven't easily been able to find out what changes, if any will need to be made to the login post-processing code, or if CDSSO still will even pick up the post-processing. If so, in what order?
In other words, the post processing code today sets some additional session data, which is technically being set for domain A (original). Will the post process code be called before the CDSSO 'rewrites,' then the CDSSO will also rewrite the custom cookies set in the post process app from domain A to new domain 'B' as appropriate, or do I need an additional copy (with code changes?) of the post-login code?
Edited by: swegener on Jan 20, 2009 9:48 AM 
No one?
The whatever plugin in code you have at the server does get used even in CDSSO scenario. The CDSSO redirect back to the agent is the last step. When you are enabling CDSSO, only config changes you do are at the agent.
However AM/OpenSSO only sets the cookie it needs for the new domain. If you need any custom cookies, you will need to set them yourself in your custom plugin depending on what you need.
Thank you for the response. The cdsso digram makes it seem like the CDSSO servlet is called first, and actually, instead of the normal login app, though, so I'm still a bit confused here.. ?
So, this is the normal process then? I'm sure I'm missing something here, as I don't get why the cdsso is specified in the agent side, versus on the AM server side..?
User Joe hits URI X, which is in domain B.
Domain B, in this case, is a vhost of Domain A, with the Policy Web Agent installed.
Web Agent redirects to the cdsso servelt INSTEAD of the normal non-csdsso login page, presumably setting some bit for the referring domain, or in the post-login URL, eg https://login-server.A/UI/Login?goto=<URI requested>
CDSSO servlet does what now? passes through to /UI/Login with the goto set back to the cdsso servlet, as well as original target URL, so the post-login code is still called after 'login,' but before going back to cdsso for domain cookie rewrites, then on to final target URI? 
Highly frustrating. I've got the IPlanetDirectoryPro SSO token being set, but the custom code to add additional domain cookies...those are not re-written by the cdservlet, and even if hard-coded for testing (I assume I can parse the domain/URI being requested by parsing the HttpServletRequest, but am just testing now) to the 'new domain,' they are sent but discarded by the browser.
This is bad, as those custom cookies are required by several apps. Is there any documentation on writing a custom cdcservlet, sample code, code for the existing one, or any other means to do this?
To be clear - 'basic' CDSSO seems to be working, if a request is made to a resource on Domain B, it directs to the AM host, which is in Domain A. The IPlanetDirectoryPro cookie is being set for Domains A and B in this case, and accepted by the browser. That setting I finally found in AMAgent.properties, here:
com.sun.am.policy.agents.config.cookie.domain.list (in case this helps someone else in the future)
However, I have post-process code implementing AMPostAuthProcessInterface which was setting custom cookies required by some apps, and I am unable to change the domain these are set in. More accurately, I can change the domain, and the data is sent, but the browser is then rejecting it, presumably as it's seeing it as a cross-domain cookie, and thus bad/discarding.
This seems to only leave me with trying to use a custom cdcservlet, assuming I can find the existing code or similar to start with, as I have no idea how it's avoiding the cross domain cookie issue..
This continues to cause problems. I'm not positive if the servlet rewrites the SSOToken (which really is the IPlanetDirectoryPro cookie, correct?) before or after post-processing. Either way, I'm stuck. I was hoping the OpenSSO cdcservlet was API compatible with AM 7, to see if it were possible to create that way, or determine how the cdcservlet was effectively setting a cross-domain cookie, but that seems a wash.
I've located the OpenSSO equivalent source for the cdcservlet, but it appears to require the ability to build all or most of OpenSSO, as there are no ant build files within that part of the tree...and while I can chase AM API calls through the OpenSSO version of the cdcservlet, it's of no use if I can't replace it, setting the cookies I need for the proper (secondary) domain.
The only other idea I've had was to use SSOToken.setProperty(), which is assuming the cdservlet either does the IPlanetDirectoryPro cookie rewrite after the post-processing code is called, or that it won't invalidate the token if I set the property in the post processing code, but this doesn't seem to be working as expected either.
Should properties set against the SSOToken be viewable via LiveHTTPHeaders or similar?

Capturing user login credential and passing it as encrypted cookie/header

Hi All,
I'm trying to capturing user login credential and passing it to the destination application in the form of encrypted string using http cookie/header. The setup we have in our testing environment is as follow:
- An Apache web server 2.0.34 with Policy agent 2.2 that is setup to accept the URL of an application and redirect to Sun Access Manager 7 for authentication.
-One authenticated, the browser is redirected back to the original application URL.
What I'm trying to achieve here is to capture the user login credentials (at access manager login application), encrypt it and set it as cookie or header string so that when it is redirect to the destination application, the information can be retrieved. However, we encounter several problems:
1. When it is redirect, the request object is a different one - we lost the information we set in the cookie/header
2. According to SAM and policy agent administrator reference and developer guide, we are suppose to be able to achieve similar task by configuring properties such as Profile, Session, or Response attribute in the AMAgent.properties. We have configured as documented but we can see no effect (policy agent log doesn't show any error neither.)
One thing we notice though, is that a cookie named iPlanetDirectoryPro was set while the reques is in SAM and then after redirected back to the original application URL, it is still there but not our own custom cookie/header string.
Does any one know what's wrong with the above setup? Did we missed something in configuration?
Any help is greatly appreciated.