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]> 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] > > 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 > -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
