CAS And Shibboleth SSO

Tue Aug 1 14:22:10 EDT 2017

Hi David, thanks for asking this question - we are also pursuing the same strategy.

Currently we have our Shib IDP v2 delegate authentication to our external CAS 3.5 server.  This makes for a very seamless SSO experience between on-premise and off-campus applications.

AFAIK, this is possible with a Shib IDP v3 deployment that handles both SSO for CAS clients, and remote Shib SPs.

Corey S.

Corey Scholefield | coreys at uvic.ca<mailto:coreys at uvic.ca>
Sr. Identity Systems Analyst
University of Victoria | Victoria, B.C. Canada

University Systems
[Description: cid:503A0399-005C-4190-8638-3C32C44A5C8B]

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of David C Fuhs
Sent: August 1, 2017 10:58 AM
To: users at shibboleth.net
Subject: CAS And Shibboleth SSO

Hello all:

Our production and development IdP specifics:

Red Hat Enterprise Linux Server release 6.9 (Santiago)
Oracle Java JDK 1.8.0_131
Jetty 9.3.9
Shibboleth IdP 3.3.1

We are currently running Shibboleth IdP version 3.3.1 in production.  We are also running an old version of CAS (3.5.2.1) in production.  Our goals are to use the CAS protocol implementation in IdP V3 to eliminate CAS entirely, and to have just one single sign-on session across both CAS and Shibboleth clients.

Having followed the instructions under CASProtocolConfiguration on the wiki, we have two CAS clients successfully authenticating using IdP V3.  They share a session as expected: if one successfully logs in to CAS Client A, then no login dialog box is displayed when the user goes to access CAS Client B, he is simply granted access to the application.  The same situation exists with Shibboleth clients and applications: successfully log in to one and the user's credentials are not required again to access a second Shibboleth-protected application.

What isn't working: CAS and Shibboleth do not recognize each other's sessions: after a successful login to a Shibboleth-protected application, the user is required to enter his credentials again to access a CAS-protected application, or vice versa: the user successfully logs in to a CAS-protected application, but has to enter his credentials again if he wants to use a Shibboleth-protected application.

It appears we have addressed the four main requirements as listed under "CAS Quickstart":

Configure suitable storage service:

>From idp.properties:
idp.session.StorageService = shibboleth.StorageService
idp.cas.StorageService = shibboleth.StorageService

Add CAS protocol profiles to the default relying party:

>From relying-party.xml:
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
    <property name="profileConfigurations">
        <list>
            ....multiple lines omitted...
            <ref bean="CAS.LoginConfiguration" />
            <ref bean="CAS.ProxyConfiguration" />
            <ref bean="CAS.ValidateConfiguration" />
        </list>
    </property>
</bean>

Add verified CAS relying parties:

>From cas-protocol.xml:
<bean class="net.shibboleth.idp.cas.service.ServiceDefinition"
    c:regex=https://([A-Za-z0-9_-]+\.)*csuchico\.edu(:\d+)?/.*
    p:group="csuchico-cas-clients"
    p:authorizedToProxy="true"
    p:singleLogoutParticipant="true" />

We intend to restrict this further, but for now any on-campus clients are okay.
We will need to do CAS proxying, but have not got that far yet.

Configure SSL/TLS trust:
Not implemented yet.  Need to get basic SSO functioning before we address CAS proxies.

The IdP logs (idp-warn.log, idp-process.log) don't indicate anything obvious, other than Shibboleth or CAS not recognizing the existing session that the other protocol created.

Historically, we have made only the minimum changes from the defaults that are required.  The only heavily-customized part of our IdP installation is login.vm, which is a modified version of login.jsp from our IdP V2 installation.  To eliminate that as a variable, I am testing using the default copy of login.vm that came with IdP V3.3.1.

With a properly configured IdP V3, will a CAS client wanting access to an application honor an existing Shibboleth session (user logged into a federated application earlier) and not display a login form asking for credentials again?

Same question going the other way: will a user who has already successfully authenticated to a CAS-protected application via IdP V3 avoid seeing the login page a second time when accessing a federated application via Shibboleth?

What am I missing?

Thanks in advance for any help.

David Fuhs
Enterprise Applications
California State University, Chico

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170801/9bf287d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4292 bytes
Desc: image001.jpg
URL: <http://shibboleth.net/pipermail/users/attachments/20170801/9bf287d1/attachment-0001.jpg>