Xin,
uPortal 2.5.x and later ships with a working Java CAS client and
example configuration for making use of it.
I highly recommend you make use of that built-in support for your CAS
integration needs, using the documentation in the uPortal Manual.
http://www.ja-sig.org/wiki/x/kwA3
Scott, primary author of the JA-SIG Java CAS Client version 3.1, would
agree:
"One thing that isn't detailed [in the documentation] is the things
left out (for now):
* uPortal support. For the time being users should continue to use
what is included in the uPortal 2.x releases. uPortal 3 will support
Spring Security (which will eventually use the new client)."
The support built into uPortal for CAS integration is built on the
Yale Java CAS Client. This client does not leverage the new advanced
features of CAS 3.1, e.g. around SAML-style authentication responses,
registered and registering services, and user attribute release. So
far, by and large, this hasn't been a problem, since very few if any
uPortal deployments are making use of these advanced CAS features.
But the day will come to use these features. If it has come for you,
I highly recommend you engage the uPortal and CAS projects in making
an upgrade here to make the default support be by way of the JA-SIG
Java CAS client and thereby mainstream these features.
Why hasn't this been done already, you might reasonably ask. The main
reason is that there's an upcoming release of Acegi AKA Spring
Security in which the CAS support is apparently changing to make use
of the JA-SIG Java CAS client rather than the Yale Java CAS Client.
uPortal is also looking to move to Acegi / Spring Security rather than
the uPortal-specific security factory approach alluded to in the
configuration you quote below. One thought (my viewpoint) is that it
will be cheaper, easier, and less painful to *not* make a change to
the way uPortal implements CAS support until *after* we get to Acegi /
Spring Security, at which point we may pick up this new approach more
cheaply anyway by virtue of whatever level of integration happens in
Spring Security. (I expect additional integration effort will still
be required to e.g. get the attributes where they need to go, etc.,
but Acegi should be a better framework to be doing that in anyway.)
Eric informed everyone in this missive that without someone stepping
up to take ownership of the Spring Security API usage enhancement,
uPortal 3.0 will likely ship without that feature in place. Which to
my mind isn't that big a deal -- it is something that can be addressed
gradually. What we have is awkward but working. (However, I would
admit if pressed, that I'd love for someone to sponsor me / Unicon to
apply efforts here to implement Spring Security integration. This one
looks like oodles of fun...)
The instructions you found and linked below for making use of the JA-
SIG Java CAS Client are out of date and applied to the 3.0 release but
not the 3.1 release, in which uPortal-specific support has been removed.
http://www.ja-sig.org/wiki/x/gAMl
I have applied some tasteful graffiti to that page to stave off
further confusion.
For history and prior discussion on this topic, see this April 2007
email post and the discussions linked from it.
There have been a number of approaches to supporting CAS integration
in uPortal. Does one prefer a filter-based approach, or a non-filter-
based approach? A filter-based approach was introduced in order to
support dyamic login URLs that might convey parameters such as
channels to instantiate. Previously, support for specific security
contexts that supported CAS was hard-coded into specific
CasConnectionContext LocalConnectionContext implementations. This
meant basically that there were a number of CAS security context,
local connection context, etc. implementations running around, all not
talking to one another, and a channel looking to use CAS via a
LocalConnectionContext couldn't support various CAS approaches without
having its LCC changed.
I attempted to untangle this a bit by introducing some core CAS
support to uPortal. This takes the form of an API for CAS-supporting
security contexts and a LocalConnectionContext implementation that
traverses the available SecurityContexts for the logged in user
looking for one that implements the API. A channel making use of this
LocalConnectionContext will support all API-implementing CAS-
supporting security contexts, regardless of whether they are the two
example implementations (one filter-using, one not) that ship with
uPortal and happen to be implemented by making use of the Yale Java
CAS Client that also ships with uPortal.
I suggest that an improvement on the approach proffered in the JA-SIG
Java CAS Client 3.0.x is to produce uPortal Security Context
implementations that make use of the JA-SIG Java CAS Client but
implement the CAS-supporting security context APIs shipping with
uPortal, such that the CasConnectionContext shipping with uPortal will
successfully detect and make use of the CAS support in these new more
advanced security context implementations. The idea is that channels
need not be aware of what particular approach to CAS integration you
are using.
Hope this helps to clarify.
Andrew
Andrew Petro
uPortal release engineer
On Dec 27, 2007, at 11:39 AM, xin zhang wrote:
Hi All,
I followed the instructions here http://www.ja-sig.org/wiki/display/
CASC/JA-SIG+CAS+Client+for+Java to integrate CAS with uPortal. I
download JA-SIG CAS Java Client 3.1.0-rc1. After modifying
security.properties file by adding
root
=org.jasig.cas.client.integration.uportal.CasSecurityContextFactory
credentialToken.root=ticket
I got error.
uPortal Error
Sorry, but uPortal encountered an error that is preventing it from
rendering. The error must be corrected by system administrators. Try
again later.
I checked the package I download. There is no
org.jasig.cas.client.integration.uportal.CasSecurityContextFactory in
the package.
How to fix this error?
Thanks
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
