We do have an upgrade guide, but it's not a step-by-step here's-everything-you-need-to-change sort of doc. In general 3.4.x is 95% compatible with 3.6 and you will only run into issues with the remaining 5% if you have heavily customized your overlay. API compatibility is 100% preserved but you may just need to add/remove a few missing elements from the XML config. The general strategy is, collect the number of files your overlay has modified and catalog the changes you have made. Then, compare those files with their original stock version from 3.6 and identify what the missing changes are, and apply. You may run into a few differences if you have modified the cas-servlet.xml file, but other than that, I think you'll find it smooth.
> -----Original Message----- > From: Baron Fujimoto [mailto:ba...@hawaii.edu] > Sent: Friday, August 14, 2015 1:44 PM > To: cas-user@lists.jasig.org > Subject: Re: [cas-user] CAS protocol flow sequence: AuthN then check > service registry? > > Ok, thanks, that's helpful info. How backwards compatible is 3.5.x (or > 3.6?) to 3.4x with regard to their configs? I'm assuming there's even more > drift to the 4x stuff. I'm trying to get sense of what upgrading will > entail. In the old docs, there are some guidelines for updating within the > 3.4x or within the 3.5x lines, but not from 3.4x to other minor or major > releases that I found. I did not find it in the newer > http://jasig.github.io/ docs either, but I'm happy to RTFM if someone can > provide a pointer (a search feature for the documentation may be > helpful?). > > Aloha, > -baron > > On Fri, Aug 14, 2015 at 02:02:01PM -0400, Dmitriy Kopylenko wrote: > >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.ne > >>>> t> > >>>> > >>>> 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: > >ba...@hawaii.edu To unsubscribe, change settings or access archives, > >see http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
