If I login to the external application directly and afterwards access the portal, everything is working fine, the ticket is recognized and I do not have to enter my credentials.
Seems that the portal is messing up something with the ticket/cookie from CAS...
That can't work. AFAIK is an IFrame like another Browser window. The Cookie that you get from the CAS Server, when you log into the portal is for exactly that session. The IFrame session has nothing to do with the Portal-Session, it is just displayed inside of that Window (as i said, it is a new Browser Sandbox inside the Browser). Thats why you can't get the Session Ticket via
because one Session can't access the Attributes of another session.
you are right, I presume.
But how are you supposed to use Single Sign On with jBoss Portal if you can't integrate external apps? I've found an approach within the CAS website to wrap a portlet ( http://www.ja-sig.org/wiki/display/CASC/CAS+and+JSR-168), but this does not work and apparently cannot work, since this approach tries to read the ticket from the portlet session:
CASReceipt receipt = (CASReceipt) session.getAttribute(CASFilter.CAS_FILTER_RECEIPT);
If the ticket was there, I had no problem... Any ideas?
I went away from integrating every Application into the Portal. I now have different Applications, each running on different Servers, and with different Frameworks (Seam, Spring ...).
Each of that applications uses the CAS-Filter to enforce authentication against the CAS Server. That is configured to use the Portal User-Table.
In the Portal I have a Portlet with a Navigation Tree, so the User can first Log In and then Navigate to the Applikation he wants to use. Because everything uses CAS, he hasn't got to login again.
He can also set a Bookmark to his favorite Applikation, and go there directly, and log in directly. Works fine for me, and i don't have to integrate every Framework into Portlets, which makes real trouble ;-)
ThatÂ´s a very reasonable approach, I think and thatÂ´s probably the way to go at the moment. Thanks for your sketches!
But nevertheless, I find it a bit disappointing not to be able to do "real" integration and accumulate my applications directly into the portal, using SSO within my portlets. It seems more like a collection of bookmarks than a full-fledged portal ;-)
You can achieve all you said using JBoss portal and a SSO framework. I don't see the point of such a desintegrated portal... (Then you don't even need a portal)
Then how do you integrate an external application if not using some kind of iframe portlet? The integration works fine, as long as no authentication is required.
CAS creates a cookie (TGC, Ticket Granting Cookie) which allows you to get a service ticket. The mentioned cookie is (as it seems to me) valid for the HTTP session of the portal, but as soon as the iframe portlet tries to load the external application, another HTTP session starts, requiring authentication as well and thus presenting the CAS login screen. This is visible viewing the session ids in the browser.
CAS is working correctly as it detects an unauthorized session and I've not been able to pass the original cookie from the portal session to the portlet.
I think you have to use the portlet bridge rather than the IFrame portlet. You can find this portlet in PortletSwap. This protlet can pass the session or cookie to the external application.
You have 2 web applications in your case. So you need to connect both applications (portal and your webapp in the iFrame) to CAS
I alreadly tried the portlet bridge, but unfortunately it does not work either... Am I missing something?
And sure, Thomas has a point. A such "desintegrated" portal is bereft of many features and advantages wihich come with a portal....
I did connect both webapps to CAS and each is working with CAS (mentioned the great cas client soulwing above). The problem is that a successful login to jboss Portal is not propagated to the external application.
A login to the external application and a following login to jBoss Portal works as this approach is sharing the same session and sees the cookie.
As Soon5 said in an earlier post, the fundamental problem has to do with propagation of the CAS token to the external application which is running inside the Portal page as an IFRAME.
Web SSO in general relies on passing authentication assertions via Cookies. Due to security reasons, a Browser is not allowed to send this cookie to external applications that are exposed via an IFRAME.
What you need to do is integrate this external web application into JBoss Portal using a Portlet Bridge. In this case, the CAS integration with JBoss Portal will properly propagate the authenticated Portal session to your Portlet.
On the standalone application side, if within the same active CAS session, you access the external web application outside the Portal context, whatever CAS integration you are using for the standalone web application will authenticate your CAS token and you will have Single Sign On into your standalone web application.
Without a Portlet Bridge, I am afraid your IFRAME cannot receive the CAS token. This is a Browser architecture limitation (for obvious reasons). It has nothing to do with IFRAME running on JBoss Portal page. You will get the same result with two simple web applications exposing each other via an IFRAME, integrated via CAS
Sorry for the long reply, but I hope the explanation throws some light on your issue
Sohil, thanks very much for the good explanation... I will give the PortletBridge a try again and post my results here.
Furthermore, I am not able to read any CAS-related information from the session, i.e. via
The Soulwing Java CAS Client does not set the session attribute "edu.yale.its.tp.cas.client.filter.user". That attribute is set only by the Yale Java CAS Client.