Why does CAS ship in uPortal and how does this relate to the Gateway SSO Portlet?
Recent releases of uPortal ship configured to use Jasig CAS (the Central Authentication Service, a free and open-source single sign-on solution for the Web). This allows uPortal to support a variety of options for authenticating users and provide a compelling single sign-on framework.
Ways to think about CAS in uPortal
uPortal does not require Jasig CAS and it does not require that you use the in-built CAS server instance rather than an external instance of your choice.
CAS as an option to be disabled
uPortal continues to provide and support its own user authentication APIs, of which the used-by-default CAS implementations of those APIs are only one option. The CAS option is a good option, but other options remain viable and there's no requirement of using CAS. You could use the portal-internal APIs to implement authentication against LDAP directly, e.g., or use the remote user implementation to integrate with a Web SSO solution other than CAS.
However, CAS and its authentication handler plugins are better exercised and are being more actively maintained. It may therefore be best even when not desiring to use CAS for single sign on, to use it as the portal-internal implementation of how uPortal delivers a login user experience and validates credentials.
CAS as portal-internal software library
One of the reasons uPortal ships using CAS by default and that the uPortal developers and maintainers were attracted to this architecture of using CAS by default is that CAS is a good software library and solution for accomplishing user login with pluggable APIs and numerous available free and open source implementations of those APIs. That is, rather than uPortal developing additional implementations of its own authentication APIs to integrate with various backing stores of credentials, the project leverages CAS and CAS APIs as the place to accomplish those integrations. You can treat CAS as simply the portal-internal implementation of how to accomplish authenticating users.
CAS as portal-specific single sign-on platform
Going beyond just using CAS as the API for authenticating users, deploying CAS with uPortal provides portal-local single sign on. This needn't entail institutional implementation of Web SSO – you can treat this as a portal-specific feature. By providing CAS in uPortal, you can now use CAS to accomplish single sign on from your portal to applications.
CAS as enterprise Web single sign-on platform
Of course, CAS doesn't require uPortal any more than uPortal requires CAS. CAS is a successful and free standing enterprise Web SSO product in its own right. Rather than adopting CAS as part of the portal, CAS can be separately adopted as an enterprise Web SSO solution and uPortal configured to make use of it.
Advantages and Disadvantages of adopting CAS
- CAS is advantageous and valuable in that it is an enterprise Web SSO platform and includes features for accomplishing single sign on without credential replay.
- Accidentally implementing CAS because it ships with uPortal may be disadvantageous in that adopting a Web SSO platform may be an important decision to be made a little less casually and a little more deliberately.
How CAS relates to the Gateway SSO Portlet
Implementing CAS doesn't preclude use of the Gateway SSO portlet for credential replay or for no-credentials-involved stepping through navigation of external applications.
For some Gateway SSO integrations, the single sign on can be accomplished without password replay by use of CAS. In those cases, use of the Gateway SSO portlet should be retired in favor of CAS single sign on integrations.
An important difference between use of the Gateway SSO Portlet credential replay approach to accomplishing single sign on and the no-credential-replay enterprise single sign on integration approach of Jasig CAS is that whereas a Gateway SSO credential replay integration typically requires no change to the single-sign-on-participating-application, CASifying an application always requires some modification to the application to participate in CAS single sign on. In well-architected applications, this is a modest change to rely upon a CAS client library to participate in the CAS single sign on protocol. In some cases (where the application has strong opinions about and a lot of internal dependence on its internal modeling and use of the user credentials), "CASifying" an application can be significantly difficult.
An optional free and open source add-on for CAS and for uPortal called "ClearPass" accomplishes conveying the credentials (password) from CAS to uPortal so that it can be available for continued credential replay usages through the Gateway SSO portlet and otherwise.
The Gateway SSO Portlet has some presentation options that do not have equivalent features in CAS. CAS does not have any opinion about how to present single sign on links in the portal or how applications ought to look framed into a portal. The Gateway SSO portlet is a portlet with some UI and presentation layer for presenting single sign on integrations. The look and feel of current Gateway SSO integrations can mostly be accomplished with CAS by using other portlets to present single sign on hyperlinks or perhaps by continued use of the Gateway SSO portlet while also using CAS.
Additional References