Scott, Thanks, this is sort of the answer I figured was coming (from looking at the documentation) but was waiting for someone with a little more knowledge to confirm it :)
I'm surprised that this requirement has not come up before. My company (if we choose to go with CAS for our SSO solution) will absolutely be looking at this in the future. Maybe it's something we can provide back to the project? Eric Scott Battaglia wrote: > Eric, > > If you wish to use CAS as both a Single Sign on Server and an > authentication mechanism, you'll want to expose the CAS Service Layer as > a web service (how you want to do that is your choice). Then systems > can contact CAS with the user's credentials and receive a service ticket > for them. > > -Scott > > On 10/2/07, *Eric Miles* > <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > 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]> > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] > > On Behalf Of Eric Miles > > Sent: Tuesday, October 02, 2007 1:53 PM > > To: [email protected] > <mailto:[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 > <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> > <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]> > >> <mailto: [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]>> > >> > > [mailto:[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]> > >> <mailto:[email protected] > <mailto:[email protected]>> > >> http://tp.its.yale.edu/mailman/listinfo/cas > <http://tp.its.yale.edu/mailman/listinfo/cas> > >> > >> > >> > >> > >> -- > >> -Scott Battaglia > >> > >> LinkedIn: http://www.linkedin.com/in/scottbattaglia > <http://www.linkedin.com/in/scottbattaglia> > >> <http://www.linkedin.com/in/scottbattaglia> > >> > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > <mailto:[email protected]> > > http://tp.its.yale.edu/mailman/listinfo/cas > > _______________________________________________ > 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 > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
