There aren't too many details I can tell you. The easiest way is that your application passes some form of token to the CAS server. This token can be a key to a database row, an encrypted value (with some form of expiration time), etc. CAS would validate this token and generate a session based on it.
-Scott On Wed, Apr 22, 2009 at 1:31 PM, rrakesh <[email protected]> wrote: > > > Hi Scott -- > > I know this message if from long back, but I was trying to do some thing > like, where I want to bypass the CAS authenication but was trying to get > CAS > create the session and the GT for the user. > > Some of the scenarios in my application are, after user self register into > the application we do not want the user log back in, in this we need to > some > thing like asking CAS to create the session and ticket for us since webapp > validated the credentials. > > If you do not mind can you please provide me some references to the point > you have mentioned in this point. > > Thanks > RR > > > scott_battaglia wrote: > > > > You can tell CAS that you've authenticated the user, but two things need > > to > > occur: > > > > 1. You'll still need to redirect to CAS, as its the ONLY thing that > should > > be able to construct and set TicketGrantingTickets. There are clearly > > ways > > around that with scoping of cookies, etc. but they are not recommended. > > > > 2. You need to create some secure mechanism for communicating with the > CAS > > server. We've had people who do some form of "account creation" > > automatically instanciate a CAS session so that the user doesn't have to > > log > > in after their account is created. That's done by using a shared data > > store > > and token. The secure token is created by the application and stored in > > the > > database. The token is passed to the CAS server which extracts it from > > the > > url, authenticates the token, and constructs a principal and TGT from > that > > token. > > > > -Scott > > > > -Scott Battaglia > > PGP Public Key Id: 0x383733AA > > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > > > > On Sun, Jan 18, 2009 at 1:31 AM, Jean-Noel Colin > > <[email protected]>wrote: > > > >> Andrew > >> > >> Thanks a lot for this. So from the schema you propose, I understand that > >> there's no way around having CAS performing authentication check itself. > >> There's no way for W1 to tell CAS: 'hey, I've already authenticated the > >> user > >> successfully, please provide with with a GT for him'? > >> > >> Thanks again for your help > >> > >> Jean-Noel > >> > >> Andrew Feller a écrit : > >> > >> Jean-Noel, > >> > >> Okay, that is a better situation than what I feared. Here are my > >> thoughts: > >> > >> > >> 1. User hits W1 and is prompted to provide login credentials > >> 2. W1 makes a RESTful API call to CAS server to authenticate > >> credentials > >> 3. CAS server responds that credentials are good and gives W1 a > Ticket > >> Granting Ticket (TGT) for you to bestow on the user > >> 4. W1 sets the CASTGC** cookie with the TGT and sends the User onto > W2 > >> / W3 accordingly > >> 5. W2 / W3 are configured with CAS clients, so they will send the > User > >> to CAS for the appropriate Service Ticket (ST) as needed > >> > >> > >> ** By default, the CAS server checks for a cookie called CASTGC, which > is > >> the TGT granted from the RESTful API. This cookie should never be > >> visible > >> to a CAS-protected application. The name of this cookie can be changed > >> by > >> updating the > >> /WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml. > >> > >> There are a couple of other things though: > >> > >> > >> 1. W1 must know the name of the cookie that the CAS server checks > >> 2. The CASTGC cookie must be set for a domain that is visible to both > >> W1 and the CAS server > >> 3. The CASTGC cookie should ONLY be visible to W1 and CAS server to > >> protect from session hijacking > >> > >> > >> Hope this helps, > >> A- > >> > >> On 1/15/09 9:12 AM, "Jean-Noël Colin" > >> <[email protected]><[email protected]>wrote: > >> > >> Andrew > >> > >> W2 and W3 are CAS-enabled, so they are able to handle CAS > authentication. > >> What we need to achieve is that users log in to W1 as they do know, > >> without > >> CAS, but then, behind the scenes, W1 would get 'something' from CAS > >> server > >> that would then allow user to navigate to W2 or W3, without the need for > >> re-authenticating > >> > >> Jean-Noel > >> > >> On 15 Jan 2009, at 16:09, Andrew Feller wrote: > >> > >> Jean-Noel, > >> > >> Stupid question: W2 and W3 know nothing about CAS, correct? > >> > >> A- > >> > >> On 1/15/09 8:52 AM, "Jean-Noël Colin" > >> <[email protected]><[email protected]>wrote: > >> > >> > >> > >> Andrew > >> > >> Thanks for your answer... I had a look a the RESTful API, and if I > >> understand correctly, I'm 'simply' passing the user credentials from W1 > >> to > >> CAS server, and after successful validation of the credentials by the > CAS > >> server, a ticket is returned that can then be used by W1 to be passed to > >> W2. > >> Is this correct? > >> > >> In our case, users already log into W1 and W1 is already designed to > >> check > >> the credentials. Wouldn't there be a way for W1 to tell CAS server: > "hey, > >> the user has already logged in, could you please give me a ticket', and > >> CAS > >> server, because it trusts W1, would provide the ticket without requiring > >> user credentials (at least pwd) to be passed? > >> > >> THanks for your help > >> > >> Jean-Noel > >> > >> > >> On 15 Jan 2009, at 14:22, Andrew Feller wrote: > >> > >> > >> > >> Jean-Noel, > >> > >> It definitely seems possible if you design W1 to use the CAS 3.3.X > >> RESTful API and you are okay with W1 having access to users' credentials > >> (username and password for example), then you can have W1 issue the CAS > >> cookie (CASTGC) and the users will never know about it. If you go with > >> this > >> approach, there are several things you need to consider: > >> > >> > >> > >> > >> 1. W1 and CAS server(s) need to be within a subdomain only they have > >> access to to prevent other servers from accessing the CAS cookie > >> 2. CAS server(s) with RESTful API should only allow W1 to issues API > >> calls > >> 3. > >> 4. > >> > >> > >> In the typical ideal situation, you would never have any application > >> with > >> access to the cookies that CAS generates because someone could access > >> this > >> via malicious code and hijack their session. If your business owners > >> understand the security risk, then this is what I would probably do. > >> > >> HTH, > >> A- > >> > >> > >> On 1/15/09 2:15 AM, "Jean-Noël Colin" > >> <[email protected]><[email protected]>wrote: > >> > >> > >> > >> > >> Hello > >> > >> I was wondering if there was a way to support the setup described > below > >> with CAS. > >> > >> We have one main website (let's call it W1), through which users > >> authenticates, using a custom DB (no ldap...). We would like to add > >> associated websites (W2, W3), so that when users are logged in in W1, > >> they > >> can SSO to W2 or W3. > >> > >> The issue is that owners of W1 don't want to have a transfer to CAS > >> server to authenticate, that would be visible to end-users. > >> > >> My question would then be: is there a possibility in CAS to request a > >> ticket without having users directly authenticate to CAS server. What > >> would > >> need to be achieved is: > >> > >> > >> > >> - user logs into W1 (with no redirect to CAS, only W1) > >> - W1 requests a ticket from CAS server > >> - this ticket is then used to access W2 or W3 from W1 > >> - > >> - > >> > >> > >> Is this feasible? > >> > >> Personally, I would prefer that we design the authentication centrally > >> in > >> CAS, have W1 users authenticate in CAS server, but ok, business owners > >> are > >> business owners... > >> > >> Thanks for your help > >> > >> Jean-Noel Colin > >> > >> > >> > >> > >> ------------------------------ > >> _______________________________________________ > >> Yale CAS mailing list > >> [email protected] > >> http://tp.its.yale.edu/mailman/listinfo/cas > >> > >> > >> -- > >> Andrew Feller, Analyst > >> LSU University Information Services > >> 200 Frey Computing Services Center > >> Baton Rouge, LA 70803 > >> Office: 225.578.3737 > >> Fax: 225.578.6400 > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Andrew Feller, Analyst > >> LSU University Information Services > >> 200 Frey Computing Services Center > >> Baton Rouge, LA 70803 > >> Office: 225.578.3737 > >> Fax: 225.578.6400 > >> > >> > >> > >> > >> > >> > >> -- > >> Andrew Feller, Analyst > >> LSU University Information Services > >> 200 Frey Computing Services Center > >> Baton Rouge, LA 70803 > >> Office: 225.578.3737 > >> Fax: 225.578.6400 > >> > >> > >> -- > >> Prof. Jean-Noel Colin > >> Computer Science Faculty > >> FUNDP, Namur, Belgium > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > View this message in context: > http://www.nabble.com/CAS-Authentication-without-going-to-CAS-Server--tp21473242p23175773.html > Sent from the CAS Users mailing list archive at Nabble.com. > > > -- > 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
