CASShib & other authentication methods
ttalbott
I am exploring the CASShib integration with Shibboleth. I'm new to
CAS and I'm wondering if someone could explain the statement under
"CASShib's placement in your SSO architecture":
"CASShib is intended to run as a secondary "behind the scenes" CAS
server running in trusted mode, meaning it accepts authentication
credentials from Shibboleth and never serves up a login page
directly."
What is meant by "secondary CAS server"? If you have a primary CAS
server that potentially authenticates with something other that Shib,
how do you see this fitting into that environment? Currently, each of
our services implements a number of authentication methods (including
Shibboleth) depending on how subscribing institutions configure the
service. We want to centralize this among our services with CAS, but
I'm having a hard time conceptualizing how CASShib might fit in with
other authentication methods.
Thanks for any insight you can give,
-Tom
P.S. Is there work being done to bring CASShib up-to-date with the
latest CAS release (3.4.2)?
bkoehm
If you have Shibboleth set up, and your users are logging into
federated applications using a SSO other than CAS, then here would be
what would happen with a CASShib-enabled application:
#1) User goes to your application's login URL
#2) User will get redirected to Shibboleth which in turns redirects to
the SSO that you have set up with Shibboleth.
#3) User logs in using your standard SSO login page
#4) User is redirected back to your application
#5) You can then use the CAS client libraries in your application to
pull CAS credential information from the CASShib server.
In this environment, the user never sees a CAS login page, only the
login page you already have with your existing SSO. The CASShib
server merely exists for your application to pull credentials via the
CAS client libraries. Without CASShib you would have to "Shibbolize"
your application with a Shibboleth Service Provider. I wrote CASShib
because I felt it was a lot easier for applications on my campus to
"CASify" than to "Shibbolize". CASShib essentially is a gateway. It
gateways credential information between your application and
Shibboleth. With CASShib you still have to set up a Shibboleth
service provider, but you have to do it just once. i.e., you
Shibbolize the CASShib server instead of setting up new Shibboleth
Service Providers for each federated application you have on your
campus.
You mention you want to standardize on CAS, and that you have various
methods, both Shibboleth and non-Shibboleth, for logging in. I can't
really comment on how you're going to transition from a non-Shibboleth
non-CAS SSO to a CAS SSO. But that said, if you want to move to an
all-CAS environment (which is what we are here at UC Merced), then
this would be how it would work:
For non-federated applications (i.e., Shibboleth isn't involved):
#1) User goes to your application's login URL
#2) User gets redirected to your normal primary CAS server.
#3) User logs in using the login page on your primary CAS server
#4) User is redirected back to your application
#5) You can then use the CAS client libraries in your application to
pull CAS credential information from the primary CAS server.
For federated applications (i.e., Shibboleth is involved):
#1) User goes to your application's login URL
#2) User will get redirected to Shibboleth which in turns redirects to
your primary CAS server that you have set up with Shibboleth.
#3) User logs in using the login page on your primary CAS server
#4) User is redirected back to your application
#5) You can then use the CAS client libraries in your application to
pull CAS credential information from the CASShib server (i.e., the
CASShib is another CAS server that is not your primary CAS server).
Regarding bringing CASShib up-to-date to 3.4.2: This shouldn't be
difficult. Usually it's just a matter of merging in changes. I
should be able to do this in a week or two, but if you are eager to to
bring CASShib 3.4.2 up then I can work on merging the changes sooner
than that.
Tom Talbott
of only "Shibbolizing" at a single point. The key to what I'm trying to
accomplish is that there isn't a distinction between non-federated and
federated applications. But, there is a distinction between
non-federated and federated authentication into all of the
applications/services. We sell subscriptions to institutions and they
choose the authentication method used by their members. My hope is to
have CAS determine the authentication method within the webflow and then
execute the appropriate authentication. This works for "standard"
authentication methods, but when you add in Shibboleth things get messy
(mostly due to the unwieldiness of the Internet2 Shibboleth SP).
Here is what I hope to accomplish:
#1) User attempts to access service, is forwarded to CAS /login (The
institution, and thus the auth methods available, are derived from the
request)
#2) Flow checks for trusted authentication methods: IP, etc...
#3) If authenticated, redirect back to service with ticket
#4) Flow checks whether a federated authentication method is configured
for the profile, if so, then hand off to that authentication method and
hopefully get back attributes.
#5) If authenticated, redirect back to service with ticket
#6) Flow checks whether a standard login page should be displayed
#7) If authenticated through U/P, etc..., redirect back to service with
ticket.
#8) If the user is redirected back to the service with a ticket, then
the ticket is validated against the CAS Server and appropriate
attributes are returned.
If I try to implement all of this within a single server (integrating
CASShib with regular CAS), I run into significant problems when I get to
#4 due to how the "Shibbolization" of CAS works (I'm blaming Internet2
here for not have a good Java library). I am currently redirecting the
user's browser to the "Shibbolized" login urls
("shib/appname/login..."). I do this by looking up the registered
service and pulling out the appname. The real problem comes at #8. The
client service doesn't know whether to validate against '/samlValidate'
or '/shib/passcode/samlValidate'. There currently is nothing in the
redirect url that indicates the auth method and you have made a
conscious effort to separate the ticket registries between the
"Shibbolized" and the regular CAS. It would be ideal if the client
service could validate the ticket against a single URL.
Could you explain why you chose to have a separate ticket registry for
the CASShib implementation?
The other option for doing this would be similar to what I've read about
in reference to CAS-NG. Unfortunately, I've only been able to find a
presentation on this (www.yale.edu/tp/CASNG.ppt), and no reference
implementation. In short, they came up with a way for the "primary" CAS
server to redirect to a "secondary" CAS server for a secondary
authentication. It seemed like it was almost a "chained" CAS setup. I
could imagine possibly putting the CASShib server in an environment like
that where it would be utilized only if Shibboleth was chosen as an
authentication method by the subscribing institution. I haven't really
thought this through, though.
I'm hoping that I have missed something obvious in all of this and that
things could be much simpler. I didn't quite follow your flows below,
especially the one for "federated applications". I get lost at step
#2. Are you saying that the user is redirected to the Shibboleth IDP
via the Shibbolized CAS login path? I don't understand how #3 comes
into play then. Why would the user see the login page on your primary
CAS server?
Thanks for your time and being a sounding board.
Take care,
-Tom
on 4/2/10 2:40 PM bkoehm said the following:
bkoehm
your clients would all have Shibboleth identity providers set up and
hooked into their SSOs. But it sounds like you're trying to have each
one of your applications accommodate both clients with and without
Shib using various different SSO technologies at your clients'
locations. This isn't a use case I've had to face and I'm not sure
CASShib was designed with that in mind, but that said let me try and
answer a few of your questions. At UC Merced the way things work is
all our non-federated applications are configured to verify tickets
against our primary CAS server. The federated applications are all
configured to use the ticket verification urls on the CASShib server.
So in other words, either an app is fully federated or it's not
federated at all.
You say that the primary problem you're facing is a separation of
ticket registries. You asked why it was done that way. The answer
lies in the passcode approach. If "traditional" CAS (non-passcoded)
tickets were in the same bucket as CASShib (passcoded) tickets, then
there would be no easy way for the CAS server to know which tickets
were supposed to be protected by a passcode and which weren't. I felt
the passcodes were necessary to prevent the possibility of
unauthorized applications from grabbing attribute information using
tickets that were meant for an authorized application. In the
Shibboleth world, Application A may get a more extensive set of
attributes than Application B and I didn't want App B being able to
get at attribute information meant for App A. This may not be concern
for your company if you trust all your applications. But on campuses
such as mine, anybody can "CASify" apps.
I don't know if this is a possibility for you, but I think it would be
fairly simple to setup an application to accept two different login
entry points. And then you can tell your clients which login URL to
use for your app. For example, if your application is using the Java
CAS client, you could have something like /login_for_federated_apps
protected by a Filter set up to validate tickets on the CASShib
server. Then you'd have another URL, /login_for_nonfederated_apps
protected by a Filter set up to validate tickets on your primary CAS
server.
But chaining CAS is certainly possible. That is essentially what
CASShib is doing. The chain for us looks like: Primary CAS Server ->
Shibboleth -> CASShib. You might have to make modifications to CAS
source to do it for your use case (you can take a look at the CASShib
sources to see how to plug in customized modules).
You asked me for clarification on my federated flow example: "I get
lost at step #2. Are you saying that the user is redirected to the
Shibboleth IDP via the Shibbolized CAS login path? I don't understand
how #3 comes into play then. Why would the user see the login page on
your primary CAS server?"
Yes, the user does indeed get redirected to the Shibboleth IDP. But
there's a few redirects involved. First the user is redirected to the
CASShib login URL, and then CASShib will see that there aren't any
Shibboleth credentials present (if the user isn't already logged in),
and it will redirect to the Shibboleth login URL. From there
Shibboleth will redirect to the configured SSO login page. For us it
is our primary CAS server login page that the user gets redirected to
(but it doesn't have to be CAS. You can configure Shibboleth to use
other SSOs). Then the user gets redirected back to Shibboleth, shib
generates credentials and releases attributes, and the user finds his
or her way redirected back to the application with a casshib ticket.
The app can then validate that ticket # and get back the attributes
that Shibboleth released to CASShib. It gets to be quite a tangled
web of redirects.
Tom Talbott
better and why you have segregated the ticket registry. You are correct
in that we do not have the issue of "any" application being
"CASified". I already went ahead and unified the ticket registry for
our use and it solves the issues I had.
You are also correct that if all of the institutions we dealt with had a
Shibboleth IDP, this would all be so much simpler. Unfortunately, that
is not the case and so we have to continue to support various other
forms of authentication. We also want to keep this authentication
decision making away from the applications so they don't need to know
anything other than they user is authorized with X attributes.
As it stands, I believe I have a usable strategy integrating your
CASShib code with other authentication methods. Thanks for sharing your
work. It was very helpful in understanding how to customize CAS to
one's unorthodox needs. :)
Take care,
-Tom
on 4/5/10 1:05 PM bkoehm said the following: