I am facing an weird problem and I don't know what to do. I have a feeling that to resolve the issue there is some configuration leve changes need to be done to resolve it, but I am not getting any idea how to solve it.
My Problem : I am using WebSphere Portal 6.15 and using external Security agent to autenticate the user ( CIA Site Minder TAI Agent ).
When I am loging in to My Application (i.e on WebSphere Portal) using Site Minder agent, instead of showing user Landing Page, WebSphere Portal Get Started Screen comes, but when I refresh the page, the user landing page comes.
I am not able to understand why it is happening, as on refreshing the page, My Page appears fine, otherwise WebSphere Portal Get Started Screen comes.
Please let me know if am missing anything here.
Pinned topic WebSphere Portal 6.15 | CIA Site Minder | Protected Portal URL issue.
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-03-26T11:13:45Z at 2013-03-26T11:13:45Z by JMW98
JMW98 2000000MY61144 Posts
Re: WebSphere Portal 6.15 | CIA Site Minder | Protected Portal URL issue.2013-03-25T14:22:12ZThis is the accepted answer. This is the accepted answer.What is the first GET to Portal (.../wps/myportal/...)? Is there any WASReqURL cookie on the request? Are you using any custom authentication filters?
If you just request wps/myportal, the default authenticated page should appear:
Is this what you consider your landing page?
SystemAdmin 110000D4XK30895 Posts
Re: WebSphere Portal 6.15 | CIA Site Minder | Protected Portal URL issue.2013-03-26T05:33:13ZThis is the accepted answer. This is the accepted answer.
- JMW98 2000000MY6
Let elaborate more :
In the below scenario, it is working perfectly :
Using WebSphere Portal Login page :
1. Go to the url : http://<server_name>/wps/portal
2. Enter any valid user credential.
3. You will land of default authenticate home page.
4. Click on Edit profile link for that user on the right side.
5. Clear your browser cache/cookies.
6. Refresh the same page again (Edit profile page).
7. User lands on Portal login page.
8. Enter the same credentials again.
9. User will land on Edit Profile page. he will not be shown the authenticate home page.
But, when I am using CA TAI Agent to authenticate the user, I am facing the issue.
here are the steps which I am doing with CA TAi Agent.
1. Created a custom login page ( Not using the WebSphere Portal login page).
2. Enter the same credential used in above scenario.
3. Store the security information in the browser cookie, which will be required by Site Minder to authenticate the user.
4. Redirect to the Edit Profile Portlet page, in the custom Login Portlet.
5. Site Minder will intercept the request (../wps/myportal/..) and will check for the validity of the cookie.
6. Site Minder internally authenticate the user and provides a valid LTPA token.
7. Now the problem comes. : Instead of showing the Edit Profile page, WebSphere Portal Home page content is shown.
8. Now when I refresh the page again in the browser by just pressing F5, Edit Profile page comes.
I am not able to understand why it is happening.
Also for your questions : Is there any WASReqURL cookie on the request? : No
Are you using any custom authentication filters? : No
Please let me know if you still don't understand my problem
JMW98 2000000MY61144 Posts
Re: WebSphere Portal 6.15 | CIA Site Minder | Protected Portal URL issue.2013-03-26T11:13:45ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
I would recommend pulling a Fiddler trace and looking at the requests at #4, 7, & 8. I assume #4 is a 302 redirect. Make sure the Location of the 302 redirect matches the requested URL at #7. Then make sure the requests at #7 and #8 are exactly the same, not only the URL but also cookies WASReqURL, LTPAToken2, and JSESSIONID. Similarly for the responses. Is #7 served a 200? Is #8 served a 302?
Could you provide the URL? Remove the host name when you post into this forum - I am mainly interested in wps/myportal/... at the Location in #4's 302 and as the requested URL in 7 & 8.
It will probably take a Fiddler trace and Portal engine tracing to understand exactly what is happening here. I would not expect Portal to serve two different pages for the very same request (#7 & #8). Conflicting friendly URLs, URL mappings, or ordinals could play a role, but I would expect similar results in the working case. If the problem is not obvious from the items above, consider opening a PMR and send in the Fiddler and Portal engine traces for analysis.