Yep, that’s old. That was the behavior which was changed to check service authorization before the author transaction start in 3.5.1+ (I don’t remember the exact 3.5.x version where it went in).
Cheers, Dmitriy. > On Aug 14, 2015, at 1:59 PM, Baron Fujimoto <ba...@hawaii.edu> wrote: > > Sorry, I should have included that. Version 3.4.11. > > On Thu, Aug 13, 2015 at 10:42:17PM -0700, Misagh Moayyed wrote: >>> But wouldn't it be better to check against the registry first and >> disallowing unauthorized service URLs before bothering with >> authentication? >> >> What CAS version are you on? That is the exact current behavior. >> >>> -----Original Message----- >>> From: Baron Fujimoto [mailto:ba...@hawaii.edu] >>> Sent: Thursday, August 13, 2015 8:54 PM >>> To: cas-user@lists.jasig.org >>> Subject: [cas-user] CAS protocol flow sequence: AuthN then check service >>> registry? >>> >>> Given the following scenario: >>> >>> CAS URL: https://cas.example.com >>> Bogus unauthorized service URL: https://bogus.example.net Real >> authorized >>> serviceURL : https://authorized.example.org >>> >>> User is tricked (by phish, perhaps) to visit >>> <https://cas.example.com/cas/login?service=https://bogus.example.net> >>> >>> The user does not have an SSO session, so is presented with the CAS >> Login >>> Form. >>> >>> The user submits the form with the username, password, and login ticket >>> POSTed in the body. >>> >>> CAS authenticates the user and creates/sets an SSO session CASTGT cookie >>> in the user's browser which contains the session key for the SSO session >>> (TGT). >>> >>> It appears that at this point, CAS verifies the "?service=" parameter >>> against the registry of authorized service URLs. The user is presented >>> with the "Application Not Authorized" error. >>> >>> However, by now the user has a valid TGT, and if they subsequently visit >>> <https://authorized.example.org>, they will be able to utilize it to >> login >>> via SSO. >>> >>> Is there any reason for concern here? I believe the scope of exposure is >>> only limited to anyone who has access to the browser session (e.g. >>> say, a publically accessible computer). But wouldn't it be better to >> check >>> against the registry first and disallowing unauthorized service URLs >>> before bothering with authentication? Or perhaps destroying the TGT if >> the >>> service URL is unauthorized? >>> >>> Or am I missing something, or perhaps some best practices configuration >> of >>> CAS to mitigate against this sort of situation? >>> >>> -baron >>> -- >>> Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services >>> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum >>> >>> -- >>> You are currently subscribed to cas-user@lists.jasig.org as: >>> mmoay...@unicon.net To unsubscribe, change settings or access archives, >>> see http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: ba...@hawaii.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > dkopyle...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
