The desire for this particular client goes beyond single sign-on. Our desire is for a central source of authentication (which is a by-product of SSO). We do not want to have to configure numerous applications with the same information to support authentication, be it against LDAP, DB mechanism, etc...
These particular clients are Blackberry clients that communicate to a series of web services. This is currently done via WS-Security with UsernameToken. These clients are authenticated against some Acegi Security code we've written, configured with Spring (it might be via LDAP, custom Daos, etc). We've taken CAS and dropped in our Acegi Security code. Now SSO enabled applications use CAS for authentication purposes. If this configuration for authentication changes, we have to change it in CAS, the web service layer, some other application, etc, etc. Not only do I desire SSO, I also desire a central source for authentication. I do not want to have to configure numerous applications with LDAP and or Dao authentication schemes. I'd like to do it in one place and I was hoping CAS would provide that. Does that make any sense? Thanks again for the help. Eric Bill Bailey wrote: > Eric, > > Are your applications desktop (thick) client applications? > > Single sign-on requires that after you authenticate successfully to one > application, you remember some key information that proves to other apps > that you have already been authenticated. In the case of CAS, the ticket > granting cookie that is stored in the browser serves that purpose. > > In the absence of a browser (i.e. a common platform through which all > the applications are accessed), it isn't clear to me where this key > information would be 'remembered'. Each application that is subsequently > launched will have no idea that some other application already > authenticated the user and will have no choice but to ask for > credentials again. > > In this case, where is the single sign-on? > > Again, maybe I'm totally missing the point, but a more complete example > of how you see a typical flow going from the user's perspective would > help. > > Bill > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Eric Miles > Sent: Tuesday, October 02, 2007 1:53 PM > To: [email protected] > Subject: Re: ACEGI, CAS and stateless clients > > Scott, > > Thanks for the information. I've looked at the protocol and it seems as > > though you are still required to login through CAS's web page, something > > my clients do not have the ability to do. Is there a way to > programmatically authenticate? The credential acceptor behavior will > not work as the login ticket must have a generated (webflow id) and the > credential requestor behavior redirects the user to a login screen. > Technically, I'd like to provide the user/password in some way, shape, > or form, without requiring the user to have to browse to a CAS webpage. > > Am I offbase in my assumptions? Is what I desire unachievable with CAS > currently? > > Thanks so much, > Eric > > Scott Battaglia wrote: >> Eric, >> >> Take a look at: >> http://www.ja-sig.org/products/cas/overview/proxy_auth/index.html >> >> It details Proxy Authentication and there are links to the actual >> protocol. If you plan on using Acegi, take a look at >> www.acegisecurity.org <http://www.acegisecurity.org>. There's a guide > >> that details how to CASify an application. There should also be >> information on passing a CAS ticket via BASIC Auth. >> >> -Scott >> >> On 9/27/07, *Eric Miles* >> <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> I too am about to go down this road at looking to use CAS for >> authentication for stateless clients (web services). I have CAS >> integrated into a web application, so I have knowledge of how that > works >> and how it all ties togeter. However, I'm unsure as to where to > begin >> to look at using CAS for stateless clients. Do you have any > suggestions >> about where to look for documents and/or examples for this? >> >> Thanks so much. >> >> Eric >> >> >> Bill Bailey wrote: >> > Never mind. I found my answer. It was right in front of me all >> along. It >> > is explicitly provided in the configuration of the > ServiceProperties >> > used to configure the ProxyTicketValidator. >> > >> > >> > Bill >> > >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > *From:* [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > [mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>] *On Behalf >> > Of *Bill Bailey >> > *Sent:* Monday, August 06, 2007 11:21 AM >> > *To:* Yale CAS mailing list >> > *Subject:* ACEGI, CAS and stateless clients >> > >> > >> > >> > Hi, >> > >> > >> > >> > I am using Spring-WS, ACEGI, and CAS together to add security > to >> my web >> > services. I have gotten as far as generating a proxy ticket for >> the web >> > services to use, but I cannot determine what service I should > say the >> > ticket is for because I can't figure out what ACEGI passes as > the >> name >> > of the service when it validates the ticket. >> > >> > >> > >> > Can anyone tell me how ACEGI forms the service name when it > calls >> > proxyValidate? I have tried the name of the URL that represents >> the web >> > service endpoint, but it doesn't seem to work. And I can't find >> the URL >> > logged anywhere in the CAS log files so I can tell what service > I >> should >> > be using. >> > >> > >> > >> > Thanks. >> > >> > >> > Bill >> > >> > >> > >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> <mailto:[email protected]> >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> >> >> >> -- >> -Scott Battaglia >> >> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> <http://www.linkedin.com/in/scottbattaglia> >> > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
