Can the Gateway SSO Portlet be used with the Central Authentication Service?

Yes, with some nuances and complexities.

Gateway SSO is a browser scripting engine. For this engine you can write "recipes" that tell the browser what to do when you access a particular Gateway SSO instance.

Gateway SSO has two core features.

1. to step through arbitrarily many GETs and at most one POST.
2. to expose potentially dynamic, per-user attributes to the scripts in (1)

Feature (1) is extensible in one major way: building "bridges" at which to point your gateway, instead of pointing it at the real target application. It turns out you can get some good mileage out of that, and Shawn has some code and examples up in an article on this subject.

Feature (2) is extensible in two main ways. Out of the box, Gateway SSO supports getting those attributes from uPortal PersonAttributes and from transiently cached username and password from login. This is extensible both in terms of the sources of the attributes and in terms of transformations applied to the attributes at runtime.

These capabilities are not sufficient to solve all problems in the world.

But it turns out these capabilities are good enough to get browsers to particular pages in most target web applications. Not all. There exist some applications with which this approach just doesn't work very well.

For integrations with CAS-using applications:

There's no law that says that Gateway SSO has to use any passwords or user attributes in any given situation. Gateway SSO may be a fine engine for instructing the browser to step through a workflow that results in the target application bouncing it off CAS and picking up a standard CAS single-sign-on interaction. Think of it as the inline frame channel on steroids.

If proxy tickets are desired and helpful, someone could write the Gateway SSO plugin that grabs a proxy ticket and makes it available to the client-side workflow engine. Bear in mind that Gateway SSO does not use a web proxy approach. It is not the portal that is retrieving content, it is the end user's web browser retrieving the content in a way instructed by the portal. Traditional CAS single sign on and service tickets are often sufficient for integrations of this style.

For integrations with non-CAS-using applications:

Gateway SSO can apply feature (2) only to data to which it actually has access. In standard CASified uPortal, there's no password available to the portal. If you want Gateway SSO to use that password, it's got to get it from somewhere.

You could put the password into LDAP or an RDBMS or in any user attribute source. You don't have to store it in plaintext -- you could have the Gateway SSO portlet decrypt it (server side) just in time for use along the lines of the way the portlet treats the passwords users enter directly into it for safe keeping (when you use that configuration).

You could hack CAS to pass the password along to the portal and add a new source of portal user attributes or Gateway SSO attributes to grab that data.