Hi Ahmed, You're almost right up to step 11...
although this point seems wrong to me : > 8) FilterOne receives the xml and extracts the user name, then > creates a cookie and encrypts the user name and the remote address into > this cookie then calls AppOne. I'm not an expert with filters but, imo, a filter does not encrypt any data into a cookie but rely on session data to store information about the principal. Therefore, only the jsessionID cookie is used to track the user... > 11) Filter two detects the cookie in the http request issued by > FilterOne earlier and forwards the call to AppTwo. You're wrong here. Filter two does not detects the cookie set by filter One. Cookies are url dependent, that is to say that cookies set by an url can't be read by another url (at least it is the case with session cookies). So, FilterTwo does not detects the cookie and forwards the user to the CAS server. As the user got a TGT at step 4 (in addition to the ST), the CAS server recognise the user and deliver a second ST for AppTwo service. No proxy tickets are required here... Proxy tickets are only required when a service needs to authenticate on behalf of the user to another service (usually a non web service). I certainly didn't answer all your questions, but hope it cleared your mind a little. Romain Faris Ahmed a écrit : > Hello! > > > > I have read almost all CAS documentation and believe/think I have a good > understanding of SSO, CAS, filters…etc. but I am still no sure about one > scenario, I hope that you can help me and tell me if I am right or wrong. > > > > *Environment:* > > 1) I have a CAS 2.0 server at https://CasServer/cas > <https://casserver/cas>. > > 2) I have a web application at http://ServerOne/AppOne > <http://serverone/AppOne> with a CAS filter called *FilterOne*. > > 3) I have a second web application at http://ServerTwo/AppTwo > <http://servertwo/AppTwo> with a CAS filter called *FilterTwo*. > > > > Actions: > > 1) End user starts a web browser on a fourth computer. > > 2) User browses to http://ServerOne/AppOne > <http://serverone/AppOne>, FilterOne intercepts the request and searches > for the CAS cookie, the cookie is not found and hence the filter > redirects the user to CAS server with this URL > *https://CasServer/cas/login?service=http://ServerOne/AppOne > <https://casserver/cas/login?service=http://ServerOne/AppOne>* > > 3) The CAS server presents the login screen; user enters user name > and password and clicks OK. > > 4) The server verifies the user name and password and issues an ST > ticket (let us call it ST_One) for service *http://ServerOne/AppOne > <http://serverone/AppOne>. *At this point the CAS server remembers in > his memory that he issued *ST_One* for *http://ServerOne/AppOne > <http://serverone/AppOne>* > > 5) After issuing the ST_One the server redirects the request to > AppOne and passes the ST_One as a URL parameter. ( for simplicity I will > use AppOne for http://ServerOne/AppOne <http://serverone/AppOne>) > > 6) The filter intercepts this request again and detects the ST_One > and hence assumes that the user has just entered a correct user name and > password, so the filter will now call the CAS server with this URL *= > https://CasServer/cas/serviceValidate?** > **service=http://ServerOne/AppOne & ticket=ST_One*. > > 7) The CAS determines if it previously has issued ST_One for > AppOne, and if ST_One is still valid he returns the user name embedded > in an xml response. > > 8) FilterOne receives the xml and extracts the user name, then > creates a cookie and encrypts the user name and the remote address into > this cookie then calls AppOne. > > 9) At this point AppOne starts and has 3 infos, a user name, a > cookie and ST_One. > > > > *Summary at this point:* > > * CAS server knows that AppOne logged in successfully. > * CAS server knows that ST_One was issued to AppOne. > * CAS server made ST_One invalid right after the serviceValidate call. > * AppOne knows that it is authenticated and knows the user name. > * All subsequent calls from the end user’s browser to AppOne will be > intercepted by FilterOne, all these calls get forwarded to AppOne > because the cookie is available. > > > > *Now my problem starts *J** > > * * > > 10) Inside AppOne there is a link to > *http://ServerTwo/AppTwo/PageTwo.aspx > <http://servertwo/AppTwo/PageTwo.aspx>, *the user clicks this link and > FilterTwo comes into action. > > 11) Filter two detects the cookie in the http request issued by > FilterOne earlier and forwards the call to AppTwo. > > 12) At this point AppTwo starts and it knows it is authenticated. > > 13) For the CAS server nothing changed, the server even doesn’t know > that the end user is now accessing AppTwo > > > > *Questions:* > > 1) According to CAS architecture and documentation AppOne and > AppTwo are two separate services which means: if AppOne wants to access > AppTwo it should: > > a. Call proxyValidate and receive a PGTIOU. > > b. Use the PGTIOU and ask for a PGT. > > c. Use the PGT to ask CAS server for a PT for service > http://ServerTwo/AppTwo <http://servertwo/AppTwo> > > d. Pass the PT to AppTwo. > > e. AppTwo asks the server to validate the PT > > f. CAS server answers with a PGTIOU and a proxy chain. > > g. AppTwo checks if the proxy chain that was responsible for > creating the PT represents a trusted application. > > h. After step a –> g are done the CAS server knows that AppOne > requested to proxy\access AppTwo. > > > > Shouldn’t all these steps be done if the end user accesses a different > service? Shouldn’t all these steps be done each time a service jump or > switch is involved. > > > > > > 2) Do I have the wrong filter version, I checked the behavior in > the debugger, are there different filter implementations. I am trying to > avoid writing my own filter. > > 3) If AppOne wants to proxy a non web service, is there any > callback required (I guess not for non web services). > > 4) What if a non web service wants to proxy another non web > service how can this be done without web callbacks? > > > > Thank in advance for you help which will be highly appreciated. > > > > > > Mit freundlichen Grüßen / Kind regards > > Faris Ahmed | Development Project Manager | *Infor *| Tel: +49 (0) 6151 > 866 7814 | Fax: +49 (0) 6151 866 7088 | _mailto:[EMAIL PROTECTED] > > Postanschrift: Infor Global Solutions Darmstadt GmbH | Landwehrstr. 50, > 64293 Darmstadt | Sitz der Gesellschaft ist Darmstadt | Handelsregister: > Amtsgericht Darmstadt, HRB 5556 | Geschäftsführer: Jochen Kasper,Uwe Richter > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
