Thanks Marvin for suggesting various options. I will be interested in knowing more about the #1 option that you listed - Shibboleth. Right now, Shibboleth is being considered as an option to achieve SSO between our product and a third part product which does not use CAS.
#2 is an interesting option. I will explore more on this. #3 - The problem with this approach is the requirement that "each instance of the product should be able to function even if other instances are down". Finally, is CAS clustering an option to consider for such a requirement? Or is it supposed to be used only to provide HA? -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: Monday, November 07, 2011 11:53 PM To: [email protected] Subject: Re: [cas-user] CAS Server Federation > This is a product that we ship to customers. Customers can install multiple > instances of this product in their environment to scale out. Simply put: CAS is not a federated SSO product. Your options: - Implement federated SSO in CAS. If Shibboleth is any indication the return on investment would be (profoundly) negative for your use case. - Creative hack where CAS instances trust one another based. An authentication handler that could query another CAS server for authenticated state of a user comes to mind. - Simply change the way you distribute your product such that the CAS server component can be installed just once for N installations such that all share a single logical CAS instance. Honestly the last option sounds like the best one. Based on what you've shared, all installations should ideally share a single CAS server anyway. M -- 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
