I agree with Scott's response, but having taken the time to write this
longer response, I've gotta send it. :) ...
Peter,
CAS is primarily a web authentication solution for use at a single
institution at a time. For instance, JASIG has a CAS server up at
https://www.ja-sig.org/cas/
JASIG uses this CAS instance to authenticate JASIGers to e.g. the
HyperContent content management system for editing the JASIG website,
which is blissfully being replaced with Drupal, but that's another story.
JASIG configures this JASIG instance of the CAS server to authenticate
JASIG users against a JASIG-run user credential store. (Here it happens
to be a database of Jira users, but the point is that it's a store
selected and maintained by JASIG.) JASIG's CAS instance is for the
purpose of authenticating JASIG users.
However, there's nothing tied up in domains about this. There's nothing
technically stopping me from CASifying http://www.unicon.net/ (which
blissfully already runs Drupal) such that users could use JASIG CAS to
log in rather than using Unicon's local account store. Policy might
stop me -- CAS can be configured to register which services may use it,
etc., but there's no technical requirement that applications to which
users authenticate via https://www.ja-sig.org/cas/ share a domain or
anything else with https://www.ja-sig.org/cas/ . Unlike some other SSO
solutions, CAS does *not* rely on applications making use of CAS being
able to see cookies CAS sets.
The federation that Shibboleth and use of Shibboleth via federations
like InCommon buys you is the ability to federate authentication and
account management. If Unicon and JASIG were both using Shibboleth and
were members of a federation facilitating the exchange and configuration
of policy, then Unicon users could authenticate via a Unicon IdP to
services offered outside Unicon. I could log in via Unicon's IdP to
edit the JASIG website, and not bother with setting up a JASIG local
account and remembering another password. That's what's meant by
federation.
Hope this proves helpful.
Best wishes,
Andrew
Scott Battaglia wrote:
If you merely have applications that exist on multiple domains, then
CAS 3 will suffice. If you need to authenticate multiple sets of
users who's authoritative source are different
companies/institutions/etc. then you should look at at something that
does federation such as Shibboleth or Ping (CAS4 will do it when it
comes out also).
On Mon, Feb 9, 2009 at 3:22 PM, Thung, Peter C CIV SPAWAR SSC PAC,
56340 <[email protected] <mailto:[email protected]>> wrote:
Cas- User group,
I forget to paste in the FAQ:
http://www.ja-sig.org/products/cas/server/faq.html#9
Also does it count as cross domain and federated if we can control
or syncronize the authentication tables between the two domains,
so it is not really federated,
but the domain names on where the resources are located are
different? e.g.
app1.com <http://app1.com> and app2.net <http://app2.net>
I'm thinking if we can somehow syncronize the authentication
repository that a CAS server on the east coast is using with a CAS
server on the west coast
is using, it might work, but not sure.
-Peter
-----Original Message-----
*From:* Thung, Peter C CIV SPAWAR SSC PAC, 56340
[mailto:[email protected] <mailto:[email protected]>]
*Sent:* Monday, February 09, 2009 12:13 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* [cas-user] CAs and Single Institution versues cross
domain institutions...
I just wanted to confirm with the group:
based on this FAQ, that
CAS is a Single Institution SSO solution.
So if we have web applications running in multiple domains
federated across a WAN,
that CAS will not work for us and we will need something like
Shibboleth.
-Peter
******************************************************************
Peter Thung
SPAWAR Systems Center PACIFIC (Code 56340)
Netcentric ISR Development
Software Developer
Primary: (619) 553-6513
Secondary:(619) 553-0777
******************************************************************
--
You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as: [email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
